Issue 3306: Resume check - what state must be stored for each thread? (ots-rtf) Source: IONA (Mr. Derek Thomson, ) Nature: Uncategorized Issue Severity: Summary: On page 10-40 of the OTS specification appears a description of the checking to be performed on a Current::resume operation if checked transactions are implemented. Resume Check Before allowing a client or object to associate a transaction context with its thread of control, a check is made to ensure that this transaction context was previously associated with the execution environment of the thread. This would be true if the thread either created the transaction or received it in a transactional operation. Does this means that an unrestricted amount of state must be retained for the lifetime of each thread? That is, do all the transactions ever created in a thread, and all the transactions ever received in a transactional operation handled by that thread need to be stored so that the Control argument to "resume" can be compared against each of them to implement the check? That can't be the case, but it that's how I'm interpreting it. What is this really trying to say? Resolution: Revised Text: Actions taken: February 9, 2000: received issue Discussion: End of Annotations:===== Sender: derek@ooc.com.au Message-ID: <38A217E0.1861F574@ooc.com.au> Date: Thu, 10 Feb 2000 11:44:00 +1000 From: Derek Thomson Organization: OOC X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.2.12-20 i686) X-Accept-Language: en MIME-Version: 1.0 To: ots-rtf@omg.org CC: issues@omg.org Subject: Resume check - what state must be stored for each thread? Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: F4ld9)-'e9GRb!!G]Ce9 On page 10-40 of the OTS specification appears a description of the checking to be performed on a Current::resume operation if checked transactions are implemented. Resume Check Before allowing a client or object to associate a transaction context with its thread of control, a check is made to ensure that this transaction context was previously associated with the execution environment of the thread. This would be true if the thread either created the transaction or received it in a transactional operation. Does this means that an unrestricted amount of state must be retained for the lifetime of each thread? That is, do all the transactions ever created in a thread, and all the transactions ever received in a transactional operation handled by that thread need to be stored so that the Control argument to "resume" can be compared against each of them to implement the check? That can't be the case, but it that's how I'm interpreting it. What is this really trying to say? Sender: jon@corvette.floorboard.com Message-ID: <38A223DE.E0BCEB94@floorboard.com> Date: Wed, 09 Feb 2000 18:35:10 -0800 From: Jonathan Biggar X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.5.1 sun4m) X-Accept-Language: en MIME-Version: 1.0 To: Derek Thomson CC: ots-rtf@omg.org, issues@omg.org Subject: Re: Resume check - what state must be stored for each thread? References: <38A217E0.1861F574@ooc.com.au> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: DoGe9oAYd9nGN!!4p;e9 Derek Thomson wrote: > > On page 10-40 of the OTS specification appears a description of the > checking to be performed on a Current::resume operation if checked > transactions are implemented. > > Resume Check > > Before allowing a client or object to associate a transaction > context > with its thread of > control, a check is made to ensure that this transaction context > was > previously > associated with the execution environment of the thread. This > would be > true if the > thread either created the transaction or received it in a > transactional operation. > > Does this means that an unrestricted amount of state must be > retained > for the lifetime of each thread? That is, do all the transactions > ever > created in a thread, and all the transactions ever received in a > transactional operation handled by that thread need to be stored so > that > the Control argument to "resume" can be compared against each of > them to > implement the check? > > That can't be the case, but it that's how I'm interpreting it. What > is > this really trying to say? I suppose so. Although the OTS implementation could certainly register a resource with the coordinator that would allow it to flush the per thread knowledge once the transaction commits or rolls back. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Date: Wed, 9 Feb 2000 19:15:52 -0800 From: Blake Biesecker To: Jonathan Biggar Cc: Derek Thomson , ots-rtf@omg.org, issues@omg.org Subject: Re: Resume check - what state must be stored for each thread? Message-ID: <20000209191552.B2929@gemstone.com> References: <38A217E0.1861F574@ooc.com.au> <38A223DE.E0BCEB94@floorboard.com> Mime-Version: 1.0 X-Mailer: Mutt 1.0pre4i In-Reply-To: <38A223DE.E0BCEB94@floorboard.com>; from jon@floorboard.com on Wed, Feb 09, 2000 at 06:35:10PM -0800 X-Disclaimer: I only speak for myself, unless I expressly indicate otherwise. Content-Type: text/plain; charset=us-ascii X-UIDL: V$Oe9lf5e9_D-!!J)>e9 On Wed, Feb 09, 2000 at 06:35:10PM -0800, Jonathan Biggar wrote: > Derek Thomson wrote: > > > > On page 10-40 of the OTS specification appears a description of > the > > checking to be performed on a Current::resume operation if checked > > transactions are implemented. > > > > Resume Check > > > > Before allowing a client or object to associate a transaction > context > > with its thread of > > control, a check is made to ensure that this transaction context > was > > previously > > associated with the execution environment of the thread. This > would be > > true if the > > thread either created the transaction or received it in a > > transactional operation. > > Is this check needed? Blake > > Does this means that an unrestricted amount of state must be retained > > for the lifetime of each thread? That is, do all the transactions ever > > created in a thread, and all the transactions ever received in a > > transactional operation handled by that thread need to be stored so that > > the Control argument to "resume" can be compared against each of them to > > implement the check? > > > > That can't be the case, but it that's how I'm interpreting it. What is > > this really trying to say? > > I suppose so. Although the OTS implementation could certainly register > a resource with the coordinator that would allow it to flush the per > thread knowledge once the transaction commits or rolls back. > > -- > Jon Biggar > Floorboard Software > jon@floorboard.com > jon@biggar.org