manual transaction mode idea
Locked
 
|
Hi,
Something we've been discussing and thinking about was that numerous problems are caused by sessions in a transaction for a long time. This causes commit records to soar, unintentional write-write conflicts and who knows what. This is a universal GemStone thing and every developer in GemStone has to manage this and develop the application so that it minimises the problem. I contend that in general, sessions should be outside of a transaction at the point of logging in. My gripe is that by default, sessions are in automatic transaction mode and by implication in a transaction when logged in. (Topaz sessions are, I know that GBS sessions can be set to manual transaction mode, but this is not the default when creating session parameters.) I think that GemStone should consider changing the default of all sessions to be manual transaction mode, and outside of a transaction when logged in. This should make it a lot clearer for people starting off with GemStone that they need to start a transaction if they want to commit something. Going into automatic transaction mode should be a "know what you're doing" kind of thing. Wouldn't it be easier to manage "commit called outside of a transaction" queries than "why does my commit records accumulate"? How many times have someone logged in with topaz (or even created a new session with VisualWorks / GemTools) and forgot that they are in a transaction. As some of you may have experienced, this causes havoc on a system that has some load. What do you think? Cheers Otto |
Re: manual transaction mode idea
|
|
Otto,
Are you suggesting any change to the signal abort or lost OT behavior? That is, by default inactive sessions would become disconnected once a CR backlog develops. James On Apr 30, 2010, at 12:16 AM, Otto Behrens wrote: > Hi, > > Something we've been discussing and thinking about was that numerous > problems are caused by sessions in a transaction for a long time. This > causes commit records to soar, unintentional write-write conflicts and > who knows what. This is a universal GemStone thing and every developer > in GemStone has to manage this and develop the application so that it > minimises the problem. I contend that in general, sessions should be > outside of a transaction at the point of logging in. > > My gripe is that by default, sessions are in automatic transaction > mode and by implication in a transaction when logged in. (Topaz > sessions are, I know that GBS sessions can be set to manual > transaction mode, but this is not the default when creating session > parameters.) > > I think that GemStone should consider changing the default of all > sessions to be manual transaction mode, and outside of a transaction > when logged in. This should make it a lot clearer for people starting > off with GemStone that they need to start a transaction if they want > to commit something. Going into automatic transaction mode should be a > "know what you're doing" kind of thing. Wouldn't it be easier to > manage "commit called outside of a transaction" queries than "why does > my commit records accumulate"? > > How many times have someone logged in with topaz (or even created a > new session with VisualWorks / GemTools) and forgot that they are in a > transaction. As some of you may have experienced, this causes havoc on > a system that has some load. > > What do you think? > > Cheers > Otto |
Re: manual transaction mode idea
|
|
AFAIK sessions inside a transaction are not disconnected
Gerhard On Fri, Apr 30, 2010 at 8:28 PM, James Foster <[hidden email]> wrote: Otto, |
|
|
In reply to this post by James Foster
This has been discussed internally in the past. The down side of
implementing what you suggest is someone logging in and performing a large amount of work only to discover they can't commit it because they forget to start a transaction. Maybe it would be better to have the default transaction mode configurable? If so, where should the configuration be set? It could be done in the UserProfile object or in the gem's config file. Norm On 4/30/10 11:28 AM, James Foster wrote: > Otto, > > Are you suggesting any change to the signal abort or lost OT behavior? That is, by default inactive sessions would become disconnected once a CR backlog develops. > > James > > On Apr 30, 2010, at 12:16 AM, Otto Behrens wrote: > > >> Hi, >> >> Something we've been discussing and thinking about was that numerous >> problems are caused by sessions in a transaction for a long time. This >> causes commit records to soar, unintentional write-write conflicts and >> who knows what. This is a universal GemStone thing and every developer >> in GemStone has to manage this and develop the application so that it >> minimises the problem. I contend that in general, sessions should be >> outside of a transaction at the point of logging in. >> >> My gripe is that by default, sessions are in automatic transaction >> mode and by implication in a transaction when logged in. (Topaz >> sessions are, I know that GBS sessions can be set to manual >> transaction mode, but this is not the default when creating session >> parameters.) >> >> I think that GemStone should consider changing the default of all >> sessions to be manual transaction mode, and outside of a transaction >> when logged in. This should make it a lot clearer for people starting >> off with GemStone that they need to start a transaction if they want >> to commit something. Going into automatic transaction mode should be a >> "know what you're doing" kind of thing. Wouldn't it be easier to >> manage "commit called outside of a transaction" queries than "why does >> my commit records accumulate"? >> >> How many times have someone logged in with topaz (or even created a >> new session with VisualWorks / GemTools) and forgot that they are in a >> transaction. As some of you may have experienced, this causes havoc on >> a system that has some load. >> >> What do you think? >> >> Cheers >> Otto >> > |
|
|
In reply to this post by Gerhard Obermann
They are if they are idle for too long. See the stone config parameter
STN_GEM_TIMEOUT.
On 4/30/10 11:33 AM, Gerhard Obermann wrote: AFAIK sessions inside a transaction are not disconnected |
Re: manual transaction mode idea
|
|
In reply to this post by Gerhard Obermann
I was thinking of Otto's proposed default of being out of a transaction on initial login. As I see it this is trading the (lower?) possibility of a system-wide somewhat obscure problem (CR backlog) for a (higher?) possibility of a more limited (session) but obvious problem (you have been disconnected).
James On Apr 30, 2010, at 11:33 AM, Gerhard Obermann wrote: AFAIK sessions inside a transaction are not disconnected |
|
|
In reply to this post by Norm Green
Hi Norm,
> This has been discussed internally in the past. The down side of > implementing what you suggest is someone logging in and performing a large > amount of work only to discover they can't commit it because they forget to > start a transaction. Yes, that certainly is a down side, but I think more manageable because users of GemStone certainly must be aware of transaction boundaries, especially if you do a large amount of work. > Maybe it would be better to have the default transaction mode configurable? > If so, where should the configuration be set? It could be done in the > UserProfile object or in the gem's config file. That would be great to have it in the config file, I think. And even a default for user sessions in the stone log would be great. I would certainly set it. Cheers Otto |
|
|
In reply to this post by James Foster
> Are you suggesting any change to the signal abort or lost OT behavior? That is, by default inactive sessions would become disconnected once a CR backlog develops.
No, I wasn't really thinking about changing this, just the default on login. But now that you mention it, lost OT is something that I never could get my head around. I've never done anything else but log out after getting a lost OT root. Why is it necessary to leave a session in this state? Many problems we are having with our visual works service sessions messing up because the session got a lot OT root and it is logged in but cannot continue. What will be great here is to terminate the session. (Perhaps also configurable?) |
|
|
In reply to this post by James Foster
Hi James,
> I was thinking of Otto's proposed default of being out of a transaction on > initial login. As I see it this is trading the (lower?) possibility of a > system-wide somewhat obscure problem (CR backlog) for a (higher?) > possibility of a more limited (session) but obvious problem (you have been > disconnected). Yes, but why have idle sessions hanging around and eating up resources? Firstly, I'll trade obvious problems for obscure ones any day. Secondly, it's the kind of thing that occurs when there is reasonable load. This is something that sneaks up on you in a production environment and then is difficult to simulate outside of that production environment. (You can simulate it, of course, but it takes a bit more knowledge of GS to do it.) Another suggestion: have a sig abort handler (that simply aborts) installed by default. In such a configuration, I could start a transaction if I don't want to get a new view of the system. For me, there is not a single session in any of the GS systems that I've worked with, where we have not used a "just abort" sig abort handler. I'm sure this will eliminate a number of queries about sessions being terminated (and working with the more obscure lost OT root.) Cheers Otto |
|
|
In reply to this post by otto
----- "Otto Behrens" <[hidden email]> wrote: | > Are you suggesting any change to the signal abort or lost OT | behavior? That is, by default inactive sessions would become | disconnected once a CR backlog develops. | | No, I wasn't really thinking about changing this, just the default on | login. But now that you mention it, lost OT is something that I never | could get my head around. I've never done anything else but log out | after getting a lost OT root. Why is it necessary to leave a session | in this state? Many problems we are having with our visual works | service sessions messing up because the session got a lot OT root and | it is logged in but cannot continue. What will be great here is to | terminate the session. (Perhaps also configurable?) Otto, I think the lostOT is signaled so that you have a chance to save any important state using non-gemstone resources and because of that possibility we don't go around nuking gems .... I assume that it _could_ be configurable so that if you want the opportunity to do something on lostOT then you can, but otherwise the gem is nuked on lostOT ... Dale |
|
|
In reply to this post by otto
----- "Otto Behrens" <[hidden email]> wrote: | Hi James, | | > I was thinking of Otto's proposed default of being out of a | transaction on | > initial login. As I see it this is trading the (lower?) possibility | of a | > system-wide somewhat obscure problem (CR backlog) for a (higher?) | > possibility of a more limited (session) but obvious problem (you | have been | > disconnected). | | Yes, but why have idle sessions hanging around and eating up | resources? Firstly, I'll trade obvious problems for obscure ones any | day. Secondly, it's the kind of thing that occurs when there is | reasonable load. This is something that sneaks up on you in a | production environment and then is difficult to simulate outside of | that production environment. (You can simulate it, of course, but it | takes a bit more knowledge of GS to do it.) | | Another suggestion: have a sig abort handler (that simply aborts) | installed by default. In such a configuration, I could start a | transaction if I don't want to get a new view of the system. For me, | there is not a single session in any of the GS systems that I've | worked with, where we have not used a "just abort" sig abort handler. | I'm sure this will eliminate a number of queries about sessions being | terminated (and working with the more obscure lost OT root.) Otto, The maintenance, fastcgi and hyper scripts all have a sigAbort handler thread in the background, but you will notice that each of them acquires the Seaside transactionMutex to ensure that the abort is done when nothing else important is going on ... to be safe this kind of measure would always have to be taken but would be application specific... Dale |
«
Return to GLASS
|
1 view|%1 views
| Free forum by Nabble | Edit this page |