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

Mariano Martinez Peck via Glass glass at lists.gemtalksystems.com
Mon May 29 07:21:26 PDT 2017


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?

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.

Thanks a lot in advance,

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

More information about the Glass mailing list