[Glass] Do you think doing this on GemStone / Seaside is .. risky?

[Dale Henrichs via Glass]

On 05/29/2017 07:21 AM, Mariano Martinez Peck via Glass wrote:
> Hi,
>
> My question is considering that I use the default transaction 
> management that comes with Seaside in GemStone 
> (#seasideProcessRequestWithRetry:resultBlock:) and friends.
>
> I am trying to do something bizarre, I know. My ultimate goal, is to 
> be able to run a Seaside callback twice. First time to get the 
> execution time (to calculate optimal number of samples for profiling) 
> and second time to profile the callback with a sample number 
> calculated based on the first result. So... the first callback 
> execution must be "discarded" and should cause no bad side effect.
>
> I have my own subclass of WACallbackProcessingActionContinuation that 
> implements this (below code is simplified for this email purpose):
>
>  (self session sessionCache at: #'shouldProfile' ifAbsent: [ false ])
>     ifTrue: [
> *      [ super performAction ]*
> *        on: WAResponseNotification*
> *        do: [ :ex | *
> *          System abortTransaction.*
> *          System beginTransaction ].*
>       self profile: [ super performAction ] ]
>     ifFalse: [ super performAction ]
>
> As you can see, with the bold part I am trying to execute the callback 
> but do not respond back to the client. That "might" be all I need from 
> Seaside (which I may be wrong....).  But aside from that, the callback 
> may have triggered some code (imagine adding something to a queue) 
> that if I consider that such code is executed twice, then I have a 
> different behavior (I would have added 2 things into the queue instead 
> of 1). So, aside from that, I also need to abortTransaction and begin 
> new one, and I assume I would retain the session mutex.. is this correct?
The thing that concerns me is doing an abort in the "middle" of request 
handling ... I know that technically you are aborting at the end, but 
your abort will reset any modified persistent objects that were modified 
before you got to callback ... it would be safer to use nested transactions:

  (self session sessionCache at: #'shouldProfile' ifAbsent: [ false ])
     ifTrue: [
*      [ System beginNestedTransaction.
         super performAction ]*
*        on: WAResponseNotification*
*        do: [ :ex | *
*          System abortTransaction].*
       self profile: [ super performAction ] ]
     ifFalse: [ super performAction ]

This will leave any objects modified up to the point of the 
#performAction unchnaged for the second pass.
>
> Anyway, even if that code is only used when profiling I sometimes 
> profile some serious extent, in which I cannot alter data and let 
> incorrect results, so I would appreciate some thoughts from you to see 
> if at least I am not seeing something obvious.
>

I guess in your case it is necessary to isolate the profiling to the 
single action to get good data, but there is Seaside code floating 
around that allows you to turn on profiling for one or more seaside 
gems. With this approach you get profiling results from the handling of 
multiple requests ... I can dig this code up if you are interested ...

Dale
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gemtalksystems.com/mailman/private/glass/attachments/20170530/a44d09ad/attachment.html>