[Glass] Seaside applications and System writeLock:

[Paul DeBruicker via Glass]

Oh and about transactions & requests: because the lock is held in the session
its independent of the transactions & request/response cycle.  



In my use case I think there is a chance that two people hitting the same
button within milli/microseconds might both lock the objects of interest but
by attempting to lock all or none I think that helps and also the chances of
that happening are so rare as to not worry about.  For my app anyway.   I
think :)






GLASS mailing list wrote
> Hi Bruno,
> 
> 
> I don't know whether this is a good or bad strategy but this is what I'm
> doing now.  
> 
> I keep a record of the lock and the locked objects in the session.  There
> is
> only a small part of my app where I think locking is worth it.  When a
> user
> wants to interact with that part of the app I lock the interesting set of
> domain objects for them as part of the callback that loads that part of
> the
> app. If acquiring that lock fails I don't let them do what they wanted to
> do.  I just show a "I'm sorry it looks like someone else is already doing
> that" message.  If they are working with locked objects and change to
> another area of the app I release the lock on the objects.  If they log
> out
> or their session expires I release the lock.  And after they complete the
> task I release the lock.  The code is in my WASession subclass and for
> locking I've added two inst vars: #locked and #objectsToLock
> 
> MySession>>#lockObjects: someObjects
> 	objectsToLock := someObjects.
> 	self acquireLocks.
> 	^ locked
> 
> MySession>>#acquireLocks
> 	locked := true.
> 	System
> 		writeLockAll: objectsToLock
> 		ifIncomplete: [ :denied :dirty :empty | 
> 			denied notEmpty
> 				ifTrue: [ 
> 					Transcript show: 'could not lock ' , denied asCommaStringAnd.
> 					Transcript show: 'owner ' , (System lockOwners: denied first)
> asString
> ].
> 			dirty notEmpty
> 				ifTrue: [ Transcript show: 'dirty locks for ' , dirty asCommaStringAnd
> ].
> 			self clearLocks ]	
> 
> MySession>>#clearLocks
> 	self hasLockedObjects
> 		ifTrue: [ 
> 			System removeLockAll: objectsToLock.
> 			objectsToLock removeAllSuchThat: [ :ea | (System lockOwners: ea)
> isEmpty
> ].
> 			locked := objectsToLock notEmpty.
> 			locked
> 				ifTrue: [ Transcript show: 'clear lock attempted but not completed ' ,
> objectsToLock asCommaStringAnd ]
> 				ifFalse: [ objectsToLock := Array new	 ] ]	
> 
> 
> MySession>>#hasLockedObjects
> 	^ locked or: [ objectsToLock notEmpty ]
> 
> MySession>>#anyLocked: aCollection
> 	^ aCollection anySatisfy: [ :obj | (System lockOwners: obj) notEmpty ]
> 
> MySession>>#unregister
> 	self clearLocks.
> 	super unregister
> 
> MySession>>#unregistered
> 	self clearLocks.
> 	super unregistered
> 
> 
> 
> In the app itself before entering the special area I send 
> 
> self session lockObjects: self specialObjects
> self session hasLockedObjects 
>        ifTrue:[ "render the special area"] 
>        ifFalse:["render the "im sorry" message" ].
> 
> 
> 
> I haven't run into any problems yet but that doesn't mean I won't run into
> any problems with the above.  Hope this helps
> 
> 
> Paul
> 
> 
> 
> 
> 
> 
> 
> 
> GLASS mailing list wrote
>> Ciao,
>> 	
>> 	i have a Seaside application and i used		 writeLock: 	to manage
>> transaction conflicts on specific objectA.
>> 
>> 	If the code in first session get  a	 writeLock:   objectA
>> 
>> 	and before commitTransaction		  another  session  get  the		 writeLock: 	
>> on the same objectA
>> 
>> 	how does the system behave?
>> 
>> 		The last writeLock:  		how it behaves?
>> 
>> 		It resubmit the request   for  some time?  how many times?
>> 
>> 	How the Seaside framework manage this problematic?
>> 
>> 	How i cam manage it?
>> 
>> 	I read the GS64 Program Guide "Transaction and Concurrency Control" .
>> 
>> 	Is the case of using Application Write Lock ?
>> 
>> 	Thanks for considerations...
>> 
>> 		Dario
>> 
>>  
>> 
>> _______________________________________________
>> Glass mailing list
> 
>> Glass at .gemtalksystems
> 
>> http://lists.gemtalksystems.com/mailman/listinfo/glass
> 
> 
> 
> 
> 
> --
> Sent from: http://forum.world.st/GLASS-f1460844.html
> _______________________________________________
> Glass mailing list

> Glass at .gemtalksystems

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





--
Sent from: http://forum.world.st/GLASS-f1460844.html