[Glass] Seaside applications and System writeLock:

[Richard Sargent via Glass]

>
> 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 <
glass at lists.gemtalksystems.com> 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: []
>
> [image: page160image17912]
> [image: page160image18184]
> 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
> Glass at lists.gemtalksystems.com
> http://lists.gemtalksystems.com/mailman/listinfo/glass
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gemtalksystems.com/mailman/private/glass/attachments/20180307/f222ea10/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: page160image18184.png
Type: image/png
Size: 2746 bytes
Desc: not available
URL: <http://lists.gemtalksystems.com/mailman/private/glass/attachments/20180307/f222ea10/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: page160image17912.png
Type: image/png
Size: 2746 bytes
Desc: not available
URL: <http://lists.gemtalksystems.com/mailman/private/glass/attachments/20180307/f222ea10/attachment-0003.png>