Seaside into Gemstone

Dario,

As I understand it (and Dale is the authority!), the GS wrapper for Seaside acquires a lock on your session (so you don’t have two requests going to to different gems at the same time), then goes through the general Seaside calls, and attempts a commit at the end before sending the response. If the commit is successful, then the response goes to the user. If the commit fails then the framework aborts everything and retries the operation some number of times (ten?).

With this approach, the first-level implementation is to just ignore commits since the framework handles it. If you really feel that you need to be able to roll back some partial activity, then you can look at nested commits.

Also, you should be able to just ignore locks since the framework handles automatic retries if there is a conflict (“optimistic locks”). If you find that the optimistic locking approach is resulting in an excessive number of retries, then you can do an explicit lock and add the lock to the commit or abort release lock set. You should not plan to hold a lock longer than a single web request/response cycle.

So, the first-level approximation is to just ignore locks and commits and let the framework handle it.

Regards,

James

On Mar 31, 2018, at 6:28 AM, Trussardi Dario Romano via Glass <[hidden email]> wrote:

Ciao,

i'm interested to understand the Seaside framework into Gemstone.

In particular the read-write locks and the commits-abort management.

Someone developed a basic  seaside application

that allows to understand and simulate the basic behavior in gemstone.

Two seaside application clients working on the same data with read-write locks and commit.

Something that allows to play in this sense.

Thanks for considerations,

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