GLASS transaction handling

Hi there,

I'm taking a look at GemStone (it's Norbert's fault, because our interview with him on our Smalltalk Inspect podcast made my mouth water to finally try it after years of only wanting to ) and am thinking about porting a GLORP-based application over to it.

One thing that's really nice in GLORP is that I can use my business objects for validation, complex logic and so on, and if I choose to rollback, the objects get reset to the values before the transaction. So far, GemStone can do the very same thing...

...but: my app has transactions that run over the course of multiple show:'s, so the idea of every HTTP request autocommitting sounds scary to me. This would mean I have to chance a whole lot of logic of my application to make it fit into the GemStoen philosophy.

If I understand the docs and posts on this group correctly, GemStone can only handle one Transaction per moment in time per Gem, so a model like I use it in a GLORP-application (each WASession holds on to a GlorpSession and all changes made within this single session can be committed or rolled back at any time, even spanning many, many screens), would not be possible with GemStone.

Or am I missing something and I could change GLASS' default behaviour?

Thanks for your thoughts

Joachim

Joachim,

For long running transactions I think that you should look at the DALi framework[1][2][3]  that Johan Brichau and Andy Kellens put together. Yesplan[4] was originally written to work against a GOODs data base with a similar transaction model that you have described for GLORP and DALi was created to solve the long running transaction problem for GLASS ...

Dale

[1] http://www.esug.org/wiki/pier/Conferences/2011/Schedule-And-Talks/Dali
[2] http://www.youtube.com/watch?v=AR-ubQ02yzU
[3] http://ss3.gemstone.com/ss/DALi.html
[4] http://www.yesplan.be/

----- Original Message -----
| From: "jtuchel" <[hidden email]>
| To: [hidden email]
| Sent: Thursday, December 1, 2011 3:39:01 AM
| Subject: [GS/SS Beta] GLASS transaction handling
|
| Hi there,
|
| I'm taking a look at GemStone (it's Norbert's fault, because our
| http://smalltalkinspect.podspot.de/post/010-norbert-hartl-uber-vmware-gemstones/
| interview with him on our Smalltalk Inspect podcast  made my mouth
| water to
| finally try it after years of only wanting to ) and am thinking about
| porting a GLORP-based application over to it.
|
| One thing that's really nice in GLORP is that I can use my business
| objects
| for validation, complex logic and so on, and if I choose to rollback,
| the
| objects get reset to the values before the transaction. So far,
| GemStone can
| do the very same thing...
|
| ...but: my app has transactions that run over the course of multiple
| show:'s, so the idea of every HTTP request autocommitting sounds
| scary to
| me. This would mean I have to chance a whole lot of logic of my
| application
| to make it fit into the GemStoen philosophy.
|
| If I understand the docs and posts on this group correctly, GemStone
| can
| only handle one Transaction per moment in time per Gem, so a model
| like I
| use it in a GLORP-application (each WASession holds on to a
| GlorpSession and
| all changes made within this single session can be committed or
| rolled back
| at any time, even spanning many, many screens), would not be possible
| with
| GemStone.
|
| Or am I missing something and I could change GLASS' default
| behaviour?
|
| Thanks for your thoughts
|
| Joachim
|
| --
| View this message in context:
| http://forum.world.st/GLASS-transaction-handling-tp4127999p4127999.html
| Sent from the GLASS mailing list archive at Nabble.com.
|

Joachim,

As Dale mentions, DALi can probably help you to some extent, however… we are also not enabling to rollback across multiple http requests.
DALi essentially allows you to detect commit conflicts between transactions made by different Seaside sessions, even when these sessions are not keeping a long-running transaction alive on the server.

When we migrated from GOODS to GLASS, the problem we faced was that we were keeping a database connection to GOODS per Seaside session and therefore we could use the database transaction mechanism to detect transaction conflicts. There were no transactions that spanned multiple requests, but each session kept its own database 'view'. All our transactions already fitted in a single http request, but because GLASS cannot keep a database view per Seaside session, you need DALi to detect commit conflicts.

So… if you find a way to keep your transactions to the length of a request, you can use DALi to still detect commit conflicts in your application in the same way that you use your current database by keeping a db connection per seaside session. I do not think it will be possible to include rollback possibility (at least not by falling back on Gemstone's rollback).

Maybe you can shed some more light on how you are using these long-lived transactions? Because I wonder what happens when a user does a back navigation in your setup, or closes down the browser in the middle of a long-lived transaction. In essence: when do you decide to timeout?

Johan

On 01 Dec 2011, at 18:01, Dale Henrichs wrote:

Johan, Dale,

thanks for clarifying. There's no support for 'intermediate' transactions for the back button in our application, just a long-lived transaction that gets committed or rolled back at certain user actions. So if you went back and continue from there, the state of our model will not change back and forth from there.

For when we time out: it's the moment the WASession expires. We have not seen any memory or performance drawbacks of that yet, maybe just because our application is not used heavily (yet?).

I guess we'd face quite some work to boil everything down to transactions that live only for the duration of one request/response cycle. You need to put some transaction logic into your business layer then, a notion of "this is a possible state of my model that may or may not get active any time soon". To me it sounds a bit scary, but that's probably just because I haven't tried yet.

Joachim

Joachim,

We're working on nested transactions for 3.1, but not sure that that would help ...

We do the transaction per HTTP request so that session state can shared across multiple vms.

We have multiple vms because a single vm can only handle one transaction at a time and we want to be able to handle concurrent http requests.

This is a very simple model and works for lots of cases.

If you want to have 'true' long running transactions using GemStone, then you need to either dedicate a vm per user (long running transaction) or find a way to break the long running transaction up into multiple transactions.

If you have a limited and known number of users, dedicating a vm per user is not a bad option.

To break the transaction up into smaller pieces I think you need to arrange for two things:

  1) Use a "working copy" of the model that gets updated during each request.
  2) Keep a "change log" of changes made to the model during each request.

When the long running transaction is committed, you have to apply your changes (either replay the change log or splice in the "working copy"), check for conflicts and commit ... The change log is useful in the cases where you need to respond to conflicts or rollback changes to a certain point.

Dale

----- Original Message -----
| From: "jtuchel" <[hidden email]>
| To: [hidden email]
| Sent: Wednesday, December 7, 2011 4:14:55 AM
| Subject: Re: [GS/SS Beta] GLASS transaction handling
|
| Johan, Dale,
|
| thanks for clarifying. There's no support for 'intermediate'
| transactions
| for the back button in our application, just a long-lived transaction
| that
| gets committed or rolled back at certain user actions. So if you went
| back
| and continue from there, the state of our model will not change back
| and
| forth from there.
|
| For when we time out: it's the moment the WASession expires. We have
| not
| seen any memory or performance drawbacks of that yet, maybe just
| because our
| application is not used heavily (yet?).
|
| I guess we'd face quite some work to boil everything down to
| transactions
| that live only for the duration of one request/response cycle. You
| need to
| put some transaction logic into your business layer then, a notion of
| "this
| is a possible state of my model that may or may not get active any
| time
| soon". To me it sounds a bit scary, but that's probably just because
| I
| haven't tried yet.
|
| Joachim
|
| --
| View this message in context:
| http://forum.world.st/GLASS-transaction-handling-tp4127999p4168725.html
| Sent from the GLASS mailing list archive at Nabble.com.
|