Nick Ager wrote:
> Dale,
>
>
> When testing the code a little more I noticed that if I didn't
> check #hasValue returned true before calling #value the code
> would become stuck in an endless loop. I've fixed the problem
> with the following code in #value
>
> totalWait := 0.
> [totalWait < 2000 and: [(self hasValue or: [self hasError])
> not]] whileTrue: [
> System _sleepMs: 10. totalWait := totalWait + 10.
> GRPlatform current doAbortTransaction].
>
> Could performing an abort within a request cause problems?
>
>
> We don't want to abort in the middle of handling a request - we
> would lose all of the persistent changes that were made to that
> point.. this is an area where we should use the sharedCounters
> perhaps, since they are atomically updated and are non-transactional...
>
>
> Makes sense. The problem is that if the service gem completes during a
> request is there any way to receive the updated value without performing
> an abort - which, as you point out, we don't want to do as we'll lose
> all the persistent changes made to that point? Would a sharedCounter
> help in this scenario?
> If receiving updates from another gem during a request is not possible -
> then I can work round that limitation. CI could modify the Pharo version
> to work in a similar manner.
>
> Thanks
>
> Nick
>
>
Nick,
If the request completes before the response is ready, you could use a
combination of the sharedCounter (to tell you that the service gem is
ready) and a WARetryHttpRequest which essentially defers the response to
the user. With a WARetryHttpRequest you get a commit and abort before
the request is retried, so at that point you can see result from the
service gem ... I'd imagine that you'd save some state in the component
that the result from the service gem is ready so that on retry you'd
know what to do ... but at least you'd avoid the round trip back to the
browser ...
Dale
Locked
