[Glass] System>>#writeLockAll: and Seaside

[Paul DeBruicker via Glass]

Hi Dale,

No I need to lock some domain objects (that, for a few minutes, should only
be editable by User A) so other users of the Seaside app can't edit them
while User A is editing them.  

I was following the programming guide section 8.3 Controlling Concurrent
Access with Locks.


My problem occurred because I had nginx round-robin proxying to the gems and
noticed that because the Seaside session moved among the gems between
requests, User A could not unlock the objects they locked unless their
request was randomly on the gem where they acquired the locks.  


Since my earlier email I've implemented sticky sessions in nginx and can now
lock and unlock the objects.  But that doesn't ensure that User A will keep
the lock in the gem they are on dies.   

When the gem dies all locks are released, correct?

Is there a way to assign the lock to a global so that it could be released
from another Gem?  If not is hte best idea to implement a lock in the domain
model and sprinkle tests around?


Thanks

Paul







GLASS mailing list wrote
> Paul,
> 
> Are you talking about the writeLock acquired on the session in 
> WAGsMutualExclusionFilter>>handleFiltered:?
> 
> If so, the lock is acquired such that the lock is removed once a commit 
> or abort occurs ... or if the session crashes ...
> 
> These locks are held on the session object while the gem processes an 
> http request and are used to prevent multiple gems from processing 
> requests for the same session concurrently ... the lock is reliquished 
> when the gem commits or aborts (or crashes) thus allowing another gem to 
> process rquests on behalf of the session, so in this case the Seaside 
> session is "respecting the Seaside session"....
> 
> Perhaps you are looking at a different use case involving session 
> affinity or something?
> 
> Dale
> 
> On 04/27/2016 10:20 AM, PAUL DEBRUICKER via Glass wrote:
>> Hi -
>>
>> It is my understanding that the read/write locks are held by the gem
>> session.   Seaside sessions can move around among gems and also outlive
>> gems, in the event of a gem crash.
>>
>>
>> Is there a recommended way to lock objects and have them respect the
>> Seaside session, rather than the Gem session and if not how are others
>> doing locking with Seaside?
>>
>>
>> Thanks
>>
>> Paul
>> _______________________________________________
>> Glass mailing list
>> 

> Glass at .gemtalksystems

>> http://lists.gemtalksystems.com/mailman/listinfo/glass
> 
> _______________________________________________
> Glass mailing list

> Glass at .gemtalksystems

> http://lists.gemtalksystems.com/mailman/listinfo/glass





--
View this message in context: http://forum.world.st/System-writeLockAll-and-Seaside-tp4892423p4892452.html
Sent from the GLASS mailing list archive at Nabble.com.