[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
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?
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,
--
Mariano
http://marianopeck.wordpress.com
-------------- 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