[Glass] Seaside applications and System writeLock:

[Paul DeBruicker via Glass]

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