[Glass] Gem go down when ex retry is manage for aBlock on: do:

[Dale Henrichs]

On Fri, Jan 24, 2014 at 6:17 AM, Dario Trussardi <dario.trussardi at tiscali.it
> wrote:

> Ciao,
>
>
>
> On Thu, Jan 23, 2014 at 4:02 AM, Dario Trussardi <
> dario.trussardi at tiscali.it> wrote:
>
> The service vm is described here[1]
>
> [1] https://code.google.com/p/glassdb/wiki/ServiceVMExample
>
>>
>> >>
>> >>>   - you might be able to successfully trigger a dialog to pop up if
>> you can
>> >>>     avoid making the jquery call inside the exception block ...
>> something where you
>> >>>     set a flag inside the exception block and pop up the dialog for
>> retry in the
>> >>>     code following the exception might work as well ...
>> >>
>> >>      How i can open a pop up when exception occured ?
>> >>
>> >>      Anyone has an example about it ?
>> >>
>> >>
>> >>>
>> >>> There might be other approaches as well...
>> >>>
>>
>> I complete extrapolate the iqDialog from on: do:  exception :
>>
>>                 stampaok:= false.
>>                 erroreTcpIP := false.
>>
>>                 [ stampaok]  whileFalse:[
>>                         stampaok := true.
>>                         erroreTcpIP ifTrue:[ self jqDialog: (
>> DTRCassaDialogConferma openOnException: exRef
>>
>>                                                       onModel: dcmModel)
>>
>>       title: 'ERRORE STAMPA'. ].
>>
>>                          [TicketBaseTipoCentriCarico newOn: dcmModel
>> dettagli: tfDettagli onPrinter: rfrMaster aPrinterTicket ]
>>                                  on: PrinterError do: [:ex |    exRef :=
>> ex .
>>
>> erroreTcpIP := true.
>>
>> stampaok := false.
>>
>> ex return: false. ].
>>                                                                 ].
>>
>> Now the while loop work fine.
>>
>
> I would think that this while loop would be touchy to use in a multi-vm
> GemStone scenario since http requests would be delivered to a different vm,
> unless you are using session affinity or a single gem
>
>
> Thanks Dale,
>
> but what do you intend for session affinity ?
>

I haven't kept up with session affinity for GemStone, but I mentioned it
because that is one that the loop in seaside code might behave correctly
...

In general I don't think it is a good idea to try to get too fancy in the
seaside code (long delays, loops and forked processes) because this
fanciness doesn't work well across multiple gems ...



>
> When i have a method with temporary  variables and i do a callback  or
> a jqDialog   as on
>
> i lose this temporary data ?
>

The callback implementation preserves the temp vars on the stack, but if
the jqDialog sends a request and you are running with multiple gems the
request will not end up coming to the same gem ...  I am not really
familiar with the mechanics of a jqDialog, but I am suspicious of a loop in
a seaside reequest (on general principles) ... if the call is working for
you then it must be okay ... but I am a bit surprised (and it may just be
my ignorance:)


>
> What are the data on which i can rely,  into on environment with more gem
>  where http request would be delivered to a different vm ?
>

With the "standard way of running GemStone with multiple gems" each http
request is routed to a different gem. The seaside session state is
persisted so any gem is capable of handling the ensuing request ...

Loops in seaside response code that wrap jquery calls cause my brain to
explode because I can't imagine how the loop can ever run correctly:)  I
grant that it could just be a failure of my imagination, but that doesn't
change the fact that brain explodes trying to wrap itself around the
concept:)

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