startup script error?

> Hi,
>
> We are a bit puzzled with an error we stumbled upon.
>
> When deploying our seaside application on a GemStone Web Edition, and starting Seaside via the runSeasideGem30 script, the execution of a callback (regular or Ajax) would make the application return to its initial state.
>
> We were able to track down the problem (at least in our application) to the startSeaside30_Adaptor script.
> This script contains the line:
> System transactionMode: #manualBegin.
>
> It appears that this had the effect that all the continuations that were set during the rendering process were lost upon start/completion of the Seaside request.
> To fix this, we changed the line in the script to:
> System transactionMode: #autoBegin.
>
> This seems to fix the problem, but is this the correct solution or are we doing something else wrong ?
>
> In addition, I should note that when starting the application using another script (cannot remember which) it worked perfectly fine but the Gemtools were blocked (yes, it's the script that does not return..).
>
> best regards,
> Johan

> Johan,
>
> Are you performing transactions while processing the seaside request? I recommend that you test things pretty thoroughly if you are performing transactions while process an HTTP request.
>
> The standard mode for GLASS is to do a beginTransaction right before handling an HTTP request and then doing a commit right before returning the response, so under normal operation #manualMode is fine.
>
> A server should be in #manualMode when it is idle. A gem that is sitting in transaction while idle can cause repository bloat (commit record backlog) - the stone keeps tracks of all transaction details for the session with the oldest commit record (a commit record is created on an abort).
>
> If you are going to run in #automaticMode, you should make sure that idle gems periodically abort (the system sends out a SigAbort when it recognizes a commit record backlog building, but gems in transaction don't get sent the sigabort).
>
> An alternative to using #automaticMode would be to do a beginTransaction after your commit (aborts should definitely be avoided) so that subsequent updates aren't lost.
>
> Dale
>
> Johan Brichau wrote:
>> Hi,
>> We are a bit puzzled with an error we stumbled upon. When deploying our seaside application on a GemStone Web Edition, and starting Seaside via the runSeasideGem30 script, the execution of a callback (regular or Ajax) would make the application return to its initial state.
>> We were able to track down the problem (at least in our application) to the startSeaside30_Adaptor script.
>> This script contains the line:
>> System transactionMode: #manualBegin.
>> It appears that this had the effect that all the continuations that were set during the rendering process were lost upon start/completion of the Seaside request.
>> To fix this, we changed the line in the script to:
>> System transactionMode: #autoBegin.
>> This seems to fix the problem, but is this the correct solution or are we doing something else wrong ?
>> In addition, I should note that when starting the application using another script (cannot remember which) it worked perfectly fine but the Gemtools were blocked (yes, it's the script that does not return..).
>> best regards,
>> Johan

> Hi Dale,
>
> You are right. We were not correctly doing a beginTransaction after a commit.
> I think we fully understand how this is supposed to work now. Thanks!
>
> On 24 Aug 2010, at 17:20, Dale Henrichs wrote:
>
>> Johan,
>>
>> Are you performing transactions while processing the seaside request? I recommend that you test things pretty thoroughly if you are performing transactions while process an HTTP request.
>>
>> The standard mode for GLASS is to do a beginTransaction right before handling an HTTP request and then doing a commit right before returning the response, so under normal operation #manualMode is fine.
>>
>> A server should be in #manualMode when it is idle. A gem that is sitting in transaction while idle can cause repository bloat (commit record backlog) - the stone keeps tracks of all transaction details for the session with the oldest commit record (a commit record is created on an abort).
>>
>> If you are going to run in #automaticMode, you should make sure that idle gems periodically abort (the system sends out a SigAbort when it recognizes a commit record backlog building, but gems in transaction don't get sent the sigabort).
>>
>> An alternative to using #automaticMode would be to do a beginTransaction after your commit (aborts should definitely be avoided) so that subsequent updates aren't lost.
>>
>> Dale
>>
>> Johan Brichau wrote:
>>> Hi,
>>> We are a bit puzzled with an error we stumbled upon. When deploying our seaside application on a GemStone Web Edition, and starting Seaside via the runSeasideGem30 script, the execution of a callback (regular or Ajax) would make the application return to its initial state.
>>> We were able to track down the problem (at least in our application) to the startSeaside30_Adaptor script.
>>> This script contains the line:
>>> System transactionMode: #manualBegin.
>>> It appears that this had the effect that all the continuations that were set during the rendering process were lost upon start/completion of the Seaside request.
>>> To fix this, we changed the line in the script to:
>>> System transactionMode: #autoBegin.
>>> This seems to fix the problem, but is this the correct solution or are we doing something else wrong ?
>>> In addition, I should note that when starting the application using another script (cannot remember which) it worked perfectly fine but the Gemtools were blocked (yes, it's the script that does not return..).
>>> best regards,
>>> Johan
>