Seaside into Gemstone

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Seaside into Gemstone

GLASS mailing list
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
Reply | Threaded
Open this post in threaded view
|

Re: Seaside into Gemstone

GLASS mailing list
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



James Foster
VP of Finance and Operations
GemTalk Systems LLC
+1 503 766 4714


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