Smalltalk › Gemtalk › GLASS

Seaside applications and System writeLock:

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

5 messages Options

GLASS mailing list

Seaside applications and System writeLock:

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

GLASS mailing list

Re: Seaside applications and System writeLock:

Ciao,

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?

I have googled but i don't found an example how to manage the lock into Seaside.

I understand that the ability to manage the lock is completely depending on my code,

and that Seaside does not implement anything about it ( only beginTransaction and commitTransaction )

It's right?

But for example when i need to get a readLock: as i read in the GS64 Program guide:

System readLock: anObject

        ifDenied: []

ifChanged: [System abortTransaction]

what i can do?

In the ifDenied block i can loop for some time or many time,

waiting for the other sessions answer and do the automatic Seaside commitTransaction.

But for ifChanged block what i can do?

The: System abortTransaction is not a valid code, it's right?

And for writeLock: ?

If i have two session, sessionA manage in sequence the writeLock: for object1 and object2

and session B manage in sequence the writeLock: for object2 and object1

the system is deadlocks ?

Thanks for any considerations, reference......

Dario

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...

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

GLASS mailing list

Re: Seaside applications and System writeLock:

If i have two session, sessionA manage in sequence the writeLock: for object1 and object2
and session B manage in sequence the writeLock: for object2 and object1
the system is deadlocks ?

Dario,

This scenario is logically equivalent to using semaphores to control access to shared resources. Your *application* will deadlock if you have an inconsistent approach to control that access. In other words, always lock against object1 first, then lock against object2.

Locking against multiple objects greatly increases the complexity of your code and reduces your ability (and anyone else's!) to understand how the code will behave. I suspect, but have no data to support it, that "greatly increases" is an exponential function.

Unfortunately, I don't work with Seaside, so I cannot offer any guidance on using locks within the Seaside framework.

On Wed, Mar 7, 2018 at 9:21 AM, Trussardi Dario Romano via Glass <[hidden email]> wrote:

Ciao,
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?

I have googled but i don't found an example how to manage the lock into Seaside.

I understand that the ability to manage the lock is completely depending on my code,

and that Seaside does not implement anything about it ( only beginTransaction and commitTransaction )

It's right?

But for example when i need to get a readLock: as i read in the GS64 Program guide:

System readLock: anObject
        ifDenied: []
ifChanged: [System abortTransaction]

what i can do?

In the ifDenied block i can loop for some time or many time,

waiting for the other sessions answer and do the automatic Seaside commitTransaction.

But for ifChanged block what i can do?

The: System abortTransaction is not a valid code, it's right?

And for writeLock: ?

If i have two session, sessionA manage in sequence the writeLock: for object1 and object2

and session B manage in sequence the writeLock: for object2 and object1

the system is deadlocks ?

Thanks for any considerations, reference......

Dario

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

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

GLASS mailing list

Re: Seaside applications and System writeLock:

In reply to this post by GLASS mailing list

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@.gemtalksystems

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

--
Sent from: http://forum.world.st/GLASS-f1460844.html
_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

GLASS mailing list

Re: Seaside applications and System writeLock:

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@.gemtalksystems
>
>> http://lists.gemtalksystems.com/mailman/listinfo/glass
>
>
>
>
>
> --
> Sent from: http://forum.world.st/GLASS-f1460844.html
> _______________________________________________
> Glass mailing list