System>>#writeLockAll: and Seaside

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

System>>#writeLockAll: and Seaside

GLASS mailing list
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
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass
Reply | Threaded
Open this post in threaded view
|

Re: System>>#writeLockAll: and Seaside

GLASS mailing list
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
> [hidden email]
> http://lists.gemtalksystems.com/mailman/listinfo/glass

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass
Reply | Threaded
Open this post in threaded view
|

Re: System>>#writeLockAll: and Seaside

Paul DeBruicker
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
> [hidden email]
> http://lists.gemtalksystems.com/mailman/listinfo/glass

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass
Reply | Threaded
Open this post in threaded view
|

Re: System>>#writeLockAll: and Seaside

Richard Sargent
Administrator
Paul DeBruicker wrote
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.  
This sounds like you need to implement an application-specific locking strategy. In such an approach, you would lock the object using the GemStone capabilities, then check for or insert a "lock record" associating the object with the user, then release the GemStone lock.

When your application is finished with the object, it does much the same to release its lock. And, of course, you need a maintenance process to delete left-over application locks (those that have been around "too long").


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
> [hidden email]
> http://lists.gemtalksystems.com/mailman/listinfo/glass

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass