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

[Mariano Martinez Peck via Glass]

On Tue, May 30, 2017 at 2:07 PM, Dale Henrichs via Glass <
glass at lists.gemtalksystems.com> wrote:

>
>
> 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.
>
>
>
That's really good idea!   I finally gave up about this idea. I now shifted
my procedure with a "first simply check the number of samples and measure
running time,  adjust interval if needed, profile again "...

But...I paste (at the end of the email) the code I used as my final version
in case someone wants to follow it.



> 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 ...
>


mmmm I am not sure I am following you but I am interesting. Can you explain
me a bit more please?


-- 
Mariano
http://marianopeck.wordpress.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gemtalksystems.com/mailman/private/glass/attachments/20170531/e4bd1d70/attachment.html>