Issue 3343: Clarification - Transaction Policy (ots-rtf) Source: International Business Machines (Mr. Thomas Freund, tjfreund@us.ibm.com) Nature: Clarification Severity: Summary: Since the updates for TransactionPolicy remove all references to the TransactionalObject Interface how is backward compatibility addressed. As existing BOA/TransactionalObject implementations will continue to exist how do we expect these to interact with the proposed POA/Policy-based implementations. Resolution: resolved, see below Revised Text: Modify the Synchronization interface definition in Section 10.3.8 as follows: // TransactionalObject has been deprecated. See 10.3.10. // Use a TransactionPolicyValue of "REQUIRES_SHARED" to // indicate transactionality. interface Synchronization : TransactionalObject { void before_completion(); void after_completion(in Status status); }; The above change has to be reflected in the CosTransactions module 10.6. Modify the text in section 10.3.10 as follows: Replace the first paragraph with: The TransactionalObject interface is a remnant of previous versions of this specification and is no longer used. It is retained here only for backward compatibility with OTS 1.0 and OTS 1.1. [ Box showing interface TransactionalObject {}; ] The above is to be done instead of removing that section. Adding this section back to the specification will mean that the following sections will need to be renumbered: Renumber the section called "Transaction Policy" (added by Messaging) from 10.3.10 to 10.3.11. Renumber the section called "Creating Transactional Object References" (added by Messaging) from 10.3.11 to 10.3.12. Add these two line to the CosTransactions module in section 10.6: // TransactionalObject has been deprecated. See 10.3.10. interface TransactionalObject {}; Actions taken: February 22, 2000: received issue January 9, 2001: closed issue Discussion: Instead of completely removing the TransactionalObject interface, it will instead be deprecated with a note saying that it is in the CosTransactions module only for backward compatibility with OTS 1.0 and 1.1. The Synchronization interface will also still inherit from TransactionalObject. End of Annotations:===== >From: TJFREUND@uk.ibm.com X-Lotus-FromDomain: IBMGB To: ots-rtf@omg.org Message-ID: <8025688D.004A6227.00@d06mta03.portsmouth.uk.ibm.com> Date: Tue, 22 Feb 2000 13:27:56 +0000 Subject: Clarification - Transaction Policy Mime-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset=us-ascii X-UIDL: -[\!!XfBe9XZSd9V8Nd9 Since the updates for TransactionPolicy remove all references to the TransactionalObject Interface how is backward compatibility addressed. As existing BOA/TransactionalObject implementations will continue to exist how do we expect these to interact with the proposed POA/Policy-based implementations. Regards, Tom Freund IBM Hursley, UK 44-1962-816150 tjfreund@uk.ibm.com From: "Mark Little" To: , References: <8025688D.004A6227.00@d06mta03.portsmouth.uk.ibm.com> Subject: Re: Clarification - Transaction Policy Date: Thu, 24 Feb 2000 10:29:14 -0000 Organization: Newcastle University MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Content-Type: text/plain; charset="iso-8859-1" X-UIDL: ;Lg!!+31e98@jd9gS#!! ----- Original Message ----- > Since the updates for TransactionPolicy remove all references to the > TransactionalObject Interface how is backward compatibility > addressed. As > existing BOA/TransactionalObject implementations will continue to > exist how > do we expect these to interact with the proposed POA/Policy-based > implementations. I agree, there needs to be some "upgrade" route (which presumably may have to co-exist for years to come). This should be an issue. I don't know how this is usually dealt with within the OMG (can this be the first time an interface in an OMG specification has been "deprecated"?) What about versioning of the IDL? Mark. ----------------------------------------------------------------------- SENDER : Dr. Mark Little, Arjuna Project, Distributed Systems Research. PHONE : +44 191 222 8066, FAX : +44 191 222 8232 POST : Department of Computing Science, University of Newcastle upon Tyne, UK, NE1 7RU EMAIL : M.C.Little@newcastle.ac.uk X-Sender: ecobb@svlhome2.beasys.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Thu, 24 Feb 2000 07:14:23 -0800 To: TJFREUND@uk.ibm.com, ots-rtf@omg.org From: Edward Cobb Subject: Re: Clarification - Transaction Policy In-Reply-To: <8025688D.004A6227.00@d06mta03.portsmouth.uk.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-UIDL: ]5B!!+]`!!bc_!!XGPe9 Tom, since propagation is completely controlled by the transaction policy component in the object reference when it is created, inheritance (or lack thereof) from TransactionalObject has no effect. Existing applications continue to run unchanged. At 01:27 PM 2/22/00 +0000, TJFREUND@uk.ibm.com wrote: > > >Since the updates for TransactionPolicy remove all references to the >TransactionalObject Interface how is backward compatibility addressed. As >existing BOA/TransactionalObject implementations will continue to exist how >do we expect these to interact with the proposed POA/Policy-based >implementations. > >Regards, >Tom Freund >IBM >Hursley, UK >44-1962-816150 >tjfreund@uk.ibm.com > > > > ************************************************************** Ed Cobb, Director, Advanced Technology & Standards BEA Systems, Inc., 2315 North First St., San Jose, CA 95131 Tel: 408-570-8264 / Fax: 408-570-8942 E-mail: ed.cobb@beasys.com ************************************************************** X-Sender: ecobb@svlhome2.beasys.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Thu, 24 Feb 2000 07:18:46 -0800 To: jis@fpk.hp.com, ots-rtf@omg.org, messaging-rtf@omg.org From: Edward Cobb Subject: Re: Question about TransactionPolicy In-Reply-To: <38B31624.73EC689D@fpk.hp.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-UIDL: ~]0!!^Pdd9A*X!!=nfd9 It's defined in the CosTransactions module. At 06:05 PM 2/22/00 -0500, Jishnu Mukerji wrote: >What module is the TransactionPolicy interface that came from the Messaging Spec >declared in? Need this info to complete editing the Core chapters. > >Thanks, > >Jishnu. > >-- >Jishnu Mukerji >Systems Architect > >Email: jis@fpk.hp.com Hewlett-Packard EIAL, >Tel: +1 973 443 7528 300 Campus Drive, 2E-62, >Fax: +1 973 443 7422 Florham Park, NJ 07932, USA. > > > > ************************************************************** Ed Cobb, Director, Advanced Technology & Standards BEA Systems, Inc., 2315 North First St., San Jose, CA 95131 Tel: 408-570-8264 / Fax: 408-570-8942 E-mail: ed.cobb@beasys.com ************************************************************** From: hans.kneubuehl@ubs.com X-OpenMail-Hops: 2 Date: Thu, 24 Feb 2000 19:07:38 +0100 Message-Id: Subject: Re: Clarification - Transaction Policy MIME-Version: 1.0 TO: M.C.Little@ncl.ac.uk, ots-rtf@omg.org, TJFREUND@uk.ibm.com Content-Disposition: inline; filename="BDY.TXT" ;Creation-Date="Thu, 24 Feb 2000 19:07:38 +0100" Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII ;Creation-Date="Thu, 24 Feb 2000 19:07:38 +0100" X-UIDL: n/2!!REo!!PKHe9fM2!! There is no backward compatibility issue here, at least not what the interface is concerned. Before the new transaction policies, the interface for transactional objects had to be derived from interface TransactionalObject. Now, it doesn't need to do that anymore, but it can still do so if it wants to for backward compatibility at the interface level. Of course, an ORB implementation may choose to still support objects that don't have the new transaction policies in their IORs, but only have their interface inheriting from TransactionalObject. The OTS spec clearly states how the policies that can be expressed by inheritance from TransactionalObject match to the new policies. The conclusion is that the OTS spec has done everything it has to do for backward compatibility. The rest is up to the vendors. Of course you can argue that the OTS spec should require backward compatible implementations for compliancy, but this is a different issue. Regards Hans > -----Original Message----- > From: M.C.Little [mailto:M.C.Little@ncl.ac.uk] > Sent: Thursday, February 24, 2000 11:29 AM > To: TJFREUND; ots-rtf > Cc: M.C.Little > Subject: UNAUTHENTICATED: Re: Clarification - Transaction Policy > > > > ----- Original Message ----- > > > Since the updates for TransactionPolicy remove all references to > the > > TransactionalObject Interface how is backward compatibility > addressed. As > > existing BOA/TransactionalObject implementations will > continue to exist > how > > do we expect these to interact with the proposed POA/Policy-based > > implementations. > > I agree, there needs to be some "upgrade" route (which > presumably may have > to co-exist for years to come). This should be an issue. > > I don't know how this is usually dealt with within the OMG > (can this be the > first time an interface in an OMG specification has been > "deprecated"?) What > about versioning of the IDL? > > Mark. > > -------------------------------------------------------------- > --------- > SENDER : Dr. Mark Little, Arjuna Project, Distributed Systems > Research. > PHONE : +44 191 222 8066, FAX : +44 191 222 8232 > POST : Department of Computing Science, University of Newcastle > upon > Tyne, UK, NE1 7RU > EMAIL : M.C.Little@newcastle.ac.uk > > > > From: "Mark Little" To: , , References: Subject: Re: Clarification - Transaction Policy Date: Fri, 25 Feb 2000 10:01:36 -0000 Organization: Newcastle University MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Content-Type: text/plain; charset="iso-8859-1" X-UIDL: /T\d9J">e9:PXd9;1[!! ----- Original Message ----- > There is no backward compatibility issue here, at least not what the interface > is concerned. > > Before the new transaction policies, the interface for transactional objects > had to be derived from interface TransactionalObject. Now, it doesn't need to > do that anymore, but it can still do so if it wants to for backward > compatibility at the interface level. Sorry, but I think you missed Tom's point. There is a significant backward compatibility problem here. POA based ORBs are not going to be the norm for a while, and legacy BOA based ORBs and applications will continue for some time (if COBOL is anything to go by we may be supporting them for the next 30 years ;-) !) So simply removing the TransactionalObject interface from the specification will suddenly make interoperating between new and existing objects/applications no longer work. > Of course, an ORB implementation may choose to still support objects that don't > have the new transaction policies in their IORs, but only have their interface > inheriting from TransactionalObject. No they can't. The new specification removes TransactionalObject, so you can't inherit from it. > The OTS spec clearly states how the > policies that can be expressed by inheritance from > TransactionalObject match to > the new policies. > > The conclusion is that the OTS spec has done everything it has to do > for > backward compatibility. The rest is up to the vendors. Of course you > can argue > that the OTS spec should require backward compatible implementations > for > compliancy, but this is a different issue. Sorry, but you have missed the point. The current specification simply removes TransactionalObject and talks about policies. What does a client do when talking to an existing OTS transactional object? It will not reside within a transactional POA, since it's BOA based, and the client will therefore think the object is not transactional, and will not ship any context. The client can do nothing more. There is no TransactionalObject interface for it to check. This may all be fixed if we can version the IDL. However, Tom's point is valid. This needs to be examined. Mark. ----------------------------------------------------------------------- SENDER : Dr. Mark Little, Arjuna Project, Distributed Systems Research. PHONE : +44 191 222 8066, FAX : +44 191 222 8232 POST : Department of Computing Science, University of Newcastle upon Tyne, UK, NE1 7RU EMAIL : M.C.Little@newcastle.ac.uk From: TJFREUND@uk.ibm.com X-Lotus-FromDomain: IBMGB To: "Mark Little" , hans.kneubuehl@ubs.com, ots-rtf@omg.org Message-ID: <80256890.003D79F6.00@d06mta03.portsmouth.uk.ibm.com> Date: Fri, 25 Feb 2000 11:06:48 +0000 Subject: Re: Clarification - Transaction Policy Mime-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset=us-ascii X-UIDL: =n/!!m':!!Ql`d9b+G!! Mark, You have captured my point correctly ... the complete removal of TransactionalObject from the specification is what causes the problem. Regards, Tom "Mark Little" on 25/02/2000 10:01:36 Please respond to "Mark Little" To: hans.kneubuehl@ubs.com, ots-rtf@omg.org, Tom Freund/UK/IBM@IBMGB cc: Subject: Re: Clarification - Transaction Policy ----- Original Message ----- > There is no backward compatibility issue here, at least not what the interface > is concerned. > > Before the new transaction policies, the interface for transactional objects > had to be derived from interface TransactionalObject. Now, it doesn't need to > do that anymore, but it can still do so if it wants to for backward > compatibility at the interface level. Sorry, but I think you missed Tom's point. There is a significant backward compatibility problem here. POA based ORBs are not going to be the norm for a while, and legacy BOA based ORBs and applications will continue for some time (if COBOL is anything to go by we may be supporting them for the next 30 years ;-) !) So simply removing the TransactionalObject interface from the specification will suddenly make interoperating between new and existing objects/applications no longer work. > Of course, an ORB implementation may choose to still support objects that don't > have the new transaction policies in their IORs, but only have their interface > inheriting from TransactionalObject. No they can't. The new specification removes TransactionalObject, so you can't inherit from it. > The OTS spec clearly states how the > policies that can be expressed by inheritance from > TransactionalObject match to > the new policies. > > The conclusion is that the OTS spec has done everything it has to do > for > backward compatibility. The rest is up to the vendors. Of course you > can argue > that the OTS spec should require backward compatible implementations > for > compliancy, but this is a different issue. Sorry, but you have missed the point. The current specification simply removes TransactionalObject and talks about policies. What does a client do when talking to an existing OTS transactional object? It will not reside within a transactional POA, since it's BOA based, and the client will therefore think the object is not transactional, and will not ship any context. The client can do nothing more. There is no TransactionalObject interface for it to check. This may all be fixed if we can version the IDL. However, Tom's point is valid. This needs to be examined. Mark. ----------------------------------------------------------------------- SENDER : Dr. Mark Little, Arjuna Project, Distributed Systems Research. PHONE : +44 191 222 8066, FAX : +44 191 222 8232 POST : Department of Computing Science, University of Newcastle upon Tyne, UK, NE1 7RU EMAIL : M.C.Little@newcastle.ac.uk From: hans.kneubuehl@ubs.com X-OpenMail-Hops: 2 Date: Fri, 25 Feb 2000 16:28:14 +0100 Message-Id: Subject: Re: Clarification - Transaction Policy MIME-Version: 1.0 TO: M.C.Little@ncl.ac.uk, ots-rtf@omg.org, TJFREUND@uk.ibm.com Content-Disposition: inline; filename="BDY.TXT" ;Creation-Date="Fri, 25 Feb 2000 16:28:14 +0100" Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII ;Creation-Date="Fri, 25 Feb 2000 16:28:14 +0100" X-UIDL: ch>e9LK"e9L#_d9&lf!! > -----Original Message----- > From: TJFREUND [mailto:TJFREUND@uk.ibm.com] > Sent: Friday, February 25, 2000 12:07 PM > To: M.C.Little; Hans z.h.k.k.8. Kneubuehl; ots-rtf > Cc: TJFREUND > Subject: UNAUTHENTICATED: Re: Clarification - Transaction Policy > > > > > Mark, > > You have captured my point correctly ... the complete removal > of > TransactionalObject from the specification is what causes the > problem. > > Regards, > Tom > Ok, do you think your concern is solved if the TransactionalObject is left in the OTS IDL and only marked with a comment as obsolete? It will then eventually be removed later when it can be assumed that all applications have moved to policies. What about the following workaround: if the TransactionalObject is completely removed, you define the interface TransactionalObject by your own, so that you still can inherit it the same way. Regards Hans -- Hans Kneubuehl, UBS AG, P.O. Box, 8098 Zurich, Switzerland phone: +41 1 238 28 96, fax: +41 1 238 30 11 From: "Mark Little" To: , , References: Subject: Re: Clarification - Transaction Policy Date: Fri, 25 Feb 2000 15:39:41 -0000 Organization: Newcastle University MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Content-Type: text/plain; charset="iso-8859-1" X-UIDL: 'lo!!#@]d9~\@e9eHCe9 ----- Original Message ----- > Ok, do you think your concern is solved if the TransactionalObject is left in > the OTS IDL and only marked with a comment as obsolete? It will then eventually > be removed later when it can be assumed that all applications have moved to > policies. We must discuss how best to do this. As I said in an earlier email I can't believe this is the first time an OMG specification has deprecated some interface (or method), so there may be some "official" way to do it. > > What about the following workaround: if the TransactionalObject is completely > removed, you define the interface TransactionalObject by your own, > so that you > still can inherit it the same way. That won't work. TransactionalObject has to reside within the CosTransactions module so that the IDL signature is correct. We're not actually just talking about writing applications with "old" IDL, but interworking with existing applications and objects, where TransactionalObject was within the CosTransactions module. A TransactionalObject interface within another module would not "narrow" for such a transactional object. Mark. ----------------------------------------------------------------------- SENDER : Dr. Mark Little, Arjuna Project, Distributed Systems Research. PHONE : +44 191 222 8066, FAX : +44 191 222 8232 POST : Department of Computing Science, University of Newcastle upon Tyne, UK, NE1 7RU EMAIL : M.C.Little@newcastle.ac.uk From: TJFREUND@uk.ibm.com X-Lotus-FromDomain: IBMGB To: hans.kneubuehl@ubs.com, M.C.Little@ncl.ac.uk, ots-rtf@omg.org Message-ID: <80256890.00569AE8.00@d06mta03.portsmouth.uk.ibm.com> Date: Fri, 25 Feb 2000 15:41:19 +0000 Subject: Re: Clarification - Transaction Policy Mime-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset=us-ascii X-UIDL: X'jd988B!!Y1Me9EU1!! Hans, Mark's suggestion was to investigate versioning the IDL (verses commenting it obsolete) ... this was in order to provide some means for a POA/Policy-based client to be able to determine that it needs to send context to a BOA/TransactionObject-based object. The problem is not how an implementation constructs a TO rather it is how someone else knows to send the context if the object is not POA/Policy-based i.e. the client needs to also check for a TO. Tom hans.kneubuehl@ubs.com on 25/02/2000 15:28:14 Please respond to hans.kneubuehl@ubs.com To: M.C.Little@ncl.ac.uk, ots-rtf@omg.org, Tom Freund/UK/IBM@IBMGB cc: Subject: Re: Clarification - Transaction Policy > -----Original Message----- > From: TJFREUND [mailto:TJFREUND@uk.ibm.com] > Sent: Friday, February 25, 2000 12:07 PM > To: M.C.Little; Hans z.h.k.k.8. Kneubuehl; ots-rtf > Cc: TJFREUND > Subject: UNAUTHENTICATED: Re: Clarification - Transaction Policy > > > > > Mark, > > You have captured my point correctly ... the complete removal > of > TransactionalObject from the specification is what causes the > problem. > > Regards, > Tom > Ok, do you think your concern is solved if the TransactionalObject is left in the OTS IDL and only marked with a comment as obsolete? It will then eventually be removed later when it can be assumed that all applications have moved to policies. What about the following workaround: if the TransactionalObject is completely removed, you define the interface TransactionalObject by your own, so that you still can inherit it the same way. Regards Hans -- Hans Kneubuehl, UBS AG, P.O. Box, 8098 Zurich, Switzerland phone: +41 1 238 28 96, fax: +41 1 238 30 11 From: hans.kneubuehl@ubs.com X-OpenMail-Hops: 2 Date: Fri, 25 Feb 2000 16:43:25 +0100 Message-Id: Subject: Re: Clarification - Transaction Policy MIME-Version: 1.0 TO: M.C.Little@ncl.ac.uk, ots-rtf@omg.org, TJFREUND@uk.ibm.com Content-Disposition: inline; filename="BDY.TXT" ;Creation-Date="Fri, 25 Feb 2000 16:43:25 +0100" Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII ;Creation-Date="Fri, 25 Feb 2000 16:43:25 +0100" X-UIDL: 1X_d9-"0e94OZd9k,-!! > -----Original Message----- > From: M.C.Little [mailto:M.C.Little@ncl.ac.uk] > Sent: Friday, February 25, 2000 4:40 PM > That won't work. TransactionalObject has to reside within the > CosTransactions module so that the IDL signature is correct. We're > not > actually just talking about writing applications with "old" IDL, but > interworking with existing applications and objects, where > TransactionalObject was within the CosTransactions module. A > TransactionalObject interface within another module would not > "narrow" for > such a transactional object. Does the Standard prohibit it to reside there? Regards Hans -- Hans Kneubuehl, UBS AG, P.O. Box, 8098 Zurich, Switzerland phone: +41 1 238 28 96, fax: +41 1 238 30 11 From: "Mark Little" To: , , References: Subject: Re: Clarification - Transaction Policy Date: Fri, 25 Feb 2000 15:48:15 -0000 Organization: Newcastle University MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Content-Type: text/plain; charset="iso-8859-1" X-UIDL: !!8L)e9l$*e9dcC!! ----- Original Message ----- > > That won't work. TransactionalObject has to reside within the > > CosTransactions module so that the IDL signature is correct. We're > not > > actually just talking about writing applications with "old" IDL, > but > > interworking with existing applications and objects, where > > TransactionalObject was within the CosTransactions module. A > > TransactionalObject interface within another module would not > > "narrow" for > > such a transactional object. > > Does the Standard prohibit it to reside there? Which Standard? This thread was started by Tom pointing out that the "new" OTS standard simply doesn't have TransactionalObject in the CosTransactions module. So if you're refering to that, then as it currently stands the answer is: yes, it does prohibit it. Mark. ----------------------------------------------------------------------- SENDER : Dr. Mark Little, Arjuna Project, Distributed Systems Research. PHONE : +44 191 222 8066, FAX : +44 191 222 8232 POST : Department of Computing Science, University of Newcastle upon Tyne, UK, NE1 7RU EMAIL : M.C.Little@newcastle.ac.uk From: hans.kneubuehl@ubs.com X-OpenMail-Hops: 2 Date: Fri, 25 Feb 2000 16:56:19 +0100 Message-Id: Subject: RE: Re: Clarification - Transaction Policy MIME-Version: 1.0 TO: hans.kneubuehl@ubs.com, M.C.Little@ncl.ac.uk, ots-rtf@omg.org, TJFREUND@uk.ibm.com Content-Disposition: inline; filename="BDY.TXT" ;Creation-Date="Fri, 25 Feb 2000 16:56:19 +0100" Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII ;Creation-Date="Fri, 25 Feb 2000 16:56:19 +0100" X-UIDL: k@[!!~'p!!"Ue!!I#=e9 > -----Original Message----- > From: M.C.Little [mailto:M.C.Little@ncl.ac.uk] > Sent: Friday, February 25, 2000 4:48 PM > To: Hans z.h.k.k.8. Kneubuehl; ots-rtf; TJFREUND > Cc: M.C.Little > Subject: UNAUTHENTICATED: Re: Clarification - Transaction Policy > > > > ----- Original Message ----- > > > > That won't work. TransactionalObject has to reside within the > > > CosTransactions module so that the IDL signature is > correct. We're not > > > actually just talking about writing applications with > "old" IDL, but > > > interworking with existing applications and objects, where > > > TransactionalObject was within the CosTransactions module. A > > > TransactionalObject interface within another module would not > > > "narrow" for > > > such a transactional object. > > > > Does the Standard prohibit it to reside there? > > Which Standard? This thread was started by Tom pointing out > that the "new" > OTS standard simply doesn't have TransactionalObject in the > CosTransactions > module. So if you're refering to that, then as it currently stands > the > answer is: yes, it does prohibit it. > Sorry, my question was unprecise. I meant (as a workaround proposal): Does the "new" OTS prohibit that an application programmer defines a CosTransactions::TransactionalObject interface on his own? Regards Hans -- Hans Kneubuehl, UBS AG, P.O. Box, 8098 Zurich, Switzerland phone: +41 1 238 28 96, fax: +41 1 238 30 11 Date: Mon, 28 Feb 2000 07:16:21 +1000 (EST) From: Michi Henning To: Mark Little cc: hans.kneubuehl@ubs.com, ots-rtf@omg.org, TJFREUND@uk.ibm.com Subject: Re: Clarification - Transaction Policy In-Reply-To: <043601bf7fa6$882c8160$6e96f080@ncl.ac.uk> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: >X!!!~DZd9ZiO!!l#Z!! On Fri, 25 Feb 2000, Mark Little wrote: > > ----- Original Message ----- > > > Ok, do you think your concern is solved if the TransactionalObject > is left > in > > the OTS IDL and only marked with a comment as obsolete? It will > then > eventually > > be removed later when it can be assumed that all applications have > moved > to > > policies. > > We must discuss how best to do this. As I said in an earlier email I > can't > believe this is the first time an OMG specification has deprecated > some > interface (or method), so there may be some "official" way to do it. Well, the "official" way is to break things... :-( If you want to add functionality, you can make a derived interface. To remove functionality, you have no option but to remove it eventually. For TransactionalObject, a new implementation can remove it but still work with older implementation. All that needs to happen is that the client has to use is_a("IDL:omg.org/CosTransactions/TransactionalObject:1.0") instead of narrow. So, I don't think removal of TransactionalObject would cause any problems. Cheers, Michi. -- Michi Henning +61 7 3891 5744 Object Oriented Concepts +61 4 1118 2700 (mobile) Suite 4, 904 Stanley St +61 7 3891 5009 (fax) East Brisbane 4169 michi@ooc.com.au AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html Date: Mon, 28 Feb 2000 07:24:08 +1000 (EST) From: Michi Henning To: Edward Cobb cc: TJFREUND@uk.ibm.com, ots-rtf@omg.org Subject: Re: Clarification - Transaction Policy In-Reply-To: <3.0.5.32.20000225083854.00b363d0@svlhome2.beasys.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: %\[!!LNY!!59'"!LbBe9 On Fri, 25 Feb 2000, Edward Cobb wrote: > The intent of the change was to allow existing applications to continue to > work. I interpret this discussion to suggest that TransactionalObject needs > to remain in the CosTransactions module even though it will never be used > by a current (CORBA 2.3) ORB. I'm not sure what the precedent is for > similar changes (assuming we've had some). > Interoperability is a clear objective including the ability to support the > old while migrating to the new. If that means that we need to keep some > text related to the TransactionalObject interface in the current spec, so > be it. I don't think we need to keep it. Old clients and servers that use TransactionalObject will be linked against the old version, so there is no problem. With the new version, interfaces simply won't compile anymore if they inherit from TransactionalObject. Cheers, Michi. -- Michi Henning +61 7 3891 5744 Object Oriented Concepts +61 4 1118 2700 (mobile) Suite 4, 904 Stanley St +61 7 3891 5009 (fax) East Brisbane 4169 michi@ooc.com.au AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html From: "Mark Little" To: "Michi Henning" , "Edward Cobb" Cc: , References: Subject: Re: Clarification - Transaction Policy Date: Mon, 28 Feb 2000 09:40:53 -0000 Organization: Newcastle University MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Content-Type: text/plain; charset="iso-8859-1" X-UIDL: @6[d9%-Rd9T3bd9 I don't think we need to keep it. Old clients and servers that use > TransactionalObject will be linked against the old version, so there > is no > problem. With the new version, interfaces simply won't compile > anymore if > they inherit from TransactionalObject. That wasn't the point. It was more to do with how "new" clients talk to "old" transactional objects (ones that reside within BOA domains). There's no recompilation at the server side, but suddently the client's stub for the server object refers to TransactionalObject, which doesn't exist. There's also the other possibility, where a BOA-based transactional client calls into a POA-based transactional server: the client won't find a TransactionalObject, and won't know anything about POA policies. Your idea about is_a would only work if recompilation is possible. For many applications that isn't a viable route. It sounds like all we can do is leave TO in the module, and put sufficient text in the specification to show that: a) it's deprecated and will (possibly) be removed later b) the disadvantages of using TO. Mark. ----------------------------------------------------------------------- SENDER : Dr. Mark Little, Arjuna Project, Distributed Systems Research. PHONE : +44 191 222 8066, FAX : +44 191 222 8232 POST : Department of Computing Science, University of Newcastle upon Tyne, UK, NE1 7RU EMAIL : M.C.Little@newcastle.ac.uk Date: Mon, 28 Feb 2000 19:50:16 +1000 (EST) From: Michi Henning To: Mark Little cc: Edward Cobb , TJFREUND@uk.ibm.com, ots-rtf@omg.org Subject: Re: Clarification - Transaction Policy In-Reply-To: <052101bf81cf$e7c84b60$6e96f080@ncl.ac.uk> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: Ei"e9E6gd94^Vd9d%)!! On Mon, 28 Feb 2000, Mark Little wrote: > > I don't think we need to keep it. Old clients and servers that use > > TransactionalObject will be linked against the old version, so > there is no > > problem. With the new version, interfaces simply won't compile > anymore if > > they inherit from TransactionalObject. > > That wasn't the point. It was more to do with how "new" clients talk > to > "old" transactional objects (ones that reside within BOA > domains). There's > no recompilation at the server side, but suddently the client's stub > for the > server object refers to TransactionalObject, which doesn't > exist. There's > also the other possibility, where a BOA-based transactional client > calls > into a POA-based transactional server: the client won't find a > TransactionalObject, and won't know anything about POA > policies. Your idea > about is_a would only work if recompilation is possible. For many > applications that isn't a viable route. It sounds like all we can do > is > leave TO in the module, and put sufficient text in the specification > to show > that: > > a) it's deprecated and will (possibly) be removed later > > b) the disadvantages of using TO. There is no problem there, at least not for backward compatibility. New clients can use old servers transparently. There is one string attached though -- you can't have interfaces of the *same* type, some of which inherit from transactional object and some which don't, in the same system. I'm not sure whether that is a serious problem or not. There is a forward compatiblity problem though: old clients can't use new servers because they won't propagate a context if the target doesn't inherit from TransactionalObject. I'm not sure whether we should let this stop us though. Basically, if we leave TransactionalObject in the spec, but deprecate it, how am I supposed to make a decision as to whether to use it? Also, the longer we leave it in there, the harder it gets to get rid of it. Basically, the idea of using inheritance from an empty interface to determine an aspect of call dispatch was, frankly, a very misguided and utterly inappropriate thing to do. I am uneasy about continuing to condone a very serious error in the object model... Cheers, Michi. -- Michi Henning +61 7 3891 5744 Object Oriented Concepts +61 4 1118 2700 (mobile) Suite 4, 904 Stanley St +61 7 3891 5009 (fax) East Brisbane 4169 michi@ooc.com.au AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html From: "Mark Little" To: "Michi Henning" Cc: "Edward Cobb" , , References: Subject: Re: Clarification - Transaction Policy Date: Mon, 28 Feb 2000 10:03:28 -0000 Organization: Newcastle University MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Content-Type: text/plain; charset="iso-8859-1" X-UIDL: L#pd9:_,!!14 There is no problem there, at least not for backward compatibility. New > clients can use old servers transparently. If this is the case then we should be ok. How though? I was under the belief that a new client will try to determine the transactional policy of the receiver's POA (remember, we're not [yet] assuming contexts get transmitted on all calls). The old object won't have one, so what is the client to do? It would be nice if it could then attempt a narrow to TransactionalObject, which I suppose it could do as you suggested. It would have been nice if IDL could be versioned though and old and new were available to the client, but that's a different issue ;-) This would obviously need to be added to the specification though (some Backward Compatibility section?) > There is one string attached > though -- you can't have interfaces of the *same* type, some of > which inherit > from transactional object and some which don't, in the same > system. I'm > not sure whether that is a serious problem or not. There's only so much you can do to provide compatibility. I'd be happy to allow this restriction. > There is a forward compatiblity problem though: old clients can't use new > servers because they won't propagate a context if the target doesn't inherit > from TransactionalObject. > > I'm not sure whether we should let this stop us though. Basically, if we > leave TransactionalObject in the spec, but deprecate it, how am I supposed > to make a decision as to whether to use it? Also, the longer we leave it > in there, the harder it gets to get rid of it. Basically, the idea of > using inheritance from an empty interface to determine an aspect of call > dispatch was, frankly, a very misguided and utterly inappropriate thing to do. > I am uneasy about continuing to condone a very serious error in the object > model... Old clients to new objects probably isn't such a big deal; it would be nice, but difficult to handle. I imagine Tom was thinking more along the lines of new clients to old objects. Mark. ----------------------------------------------------------------------- SENDER : Dr. Mark Little, Arjuna Project, Distributed Systems Research. PHONE : +44 191 222 8066, FAX : +44 191 222 8232 POST : Department of Computing Science, University of Newcastle upon Tyne, UK, NE1 7RU EMAIL : M.C.Little@newcastle.ac.uk Date: Tue, 29 Feb 2000 06:50:34 +1000 (EST) From: Michi Henning To: Mark Little cc: Edward Cobb , TJFREUND@uk.ibm.com, ots-rtf@omg.org Subject: Re: Clarification - Transaction Policy In-Reply-To: <058b01bf81d3$100ea120$6e96f080@ncl.ac.uk> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: eGa!!W['e9ERm!!iS1!! On Mon, 28 Feb 2000, Mark Little wrote: > > There is no problem there, at least not for backward compatibility. New > > clients can use old servers transparently. > > If this is the case then we should be ok. How though? I was under the belief > that a new client will try to determine the transactional policy of the > receiver's POA (remember, we're not [yet] assuming contexts get transmitted > on all calls). The old object won't have one, so what is the client to do? > It would be nice if it could then attempt a narrow to TransactionalObject, > which I suppose it could do as you suggested. Yes, that would be the idea. Try to narrow to TransactionalObject if the IOR doesn't contain a policy and send the context if it does. There is the cost though of checking this for every object (narrow requires a message on the wire) -- it might be cheaper to just send the context without trying to narrow first. If the target isn't transactional, it will ignore the context. Cheers, Michi. -- Michi Henning +61 7 3891 5744 Object Oriented Concepts +61 4 1118 2700 (mobile) Suite 4, 904 Stanley St +61 7 3891 5009 (fax) East Brisbane 4169 michi@ooc.com.au AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html Date: Tue, 28 Mar 2000 11:33:07 -0800 From: Blake Biesecker To: Chris Smith Cc: ots-rtf@omg.org, messaging-rtf@omg.org Subject: Re: issues that need to be resolved before Oslo Message-ID: <20000328113307.B13707@gemstone.com> References: <20000327133040.C7825@gemstone.com> <38E05C2B.AEE2AEBA@uab.ericsson.se> Mime-Version: 1.0 X-Mailer: Mutt 1.0pre4i In-Reply-To: <38E05C2B.AEE2AEBA@uab.ericsson.se>; from uabcsru@uab.ericsson.se on Tue, Mar 28, 2000 at 09:15:55AM +0200 X-Disclaimer: I only speak for myself, unless I expressly indicate otherwise. Content-Type: text/plain; charset=us-ascii X-UIDL: U'*!!]`6!!Qn6!!HCi!! Chris, Issue 3004 should be addressed by resolving OTS issue 3343: ------------------------------------------------------------ Issue 3343: Clarification - Transaction Policy (ots-rtf) Source: International Business Machines (Mr. Thomas Freund, tjfreund@uk.ibm.com) Nature: Clarification Severity: Summary: Since the updates for TransactionPolicy remove all references to the TransactionalObject Interface how is backward compatibility addressed. As existing BOA/TransactionalObject implementations will continue to exist how do we expect these to interact with the proposed POA/Policy-based implementations. Resolution: Revised Text: Actions taken: February 22, 2000: received issue Discussion: ------------------------------------------------------------ We will either need to remove all references to TransactionalObject or add text to describe how it maps to TransactionPolicies. Either way, the text mentioned in issue 3004 will need to be cleaned up. I think we should resolve the OTS issue 3343 first and hopefully it will allow you to close issue 3004 without action. (Or, we can transfer issue 3004 to the OTS RTF ...) I'll discuss issue 587 in a separate email. Blake On Tue, Mar 28, 2000 at 09:15:55AM +0200, Chris Smith wrote: > Issues 587 and 3004 in Messaging RTF also concern OTS, and > if you can find somebody who wants to put up a > proposal, I will gladly put it in the next vote. > > > Blake Biesecker wrote: > > > > Hello, All, > > > > We need to start getting aggressive with resolving issues, if > > we want to publish by Oslo. > > > > From what I can deduce (be warned, I haven't been following > > the Messaging RTF, so this is based on what I've seen in > > otsrtf mail), these are the open issues with regards to > > the Messaging RTF changes that we need to resolve: > > > > Issue 3417: TransactionalObject remnants > > Issue 3420: Component tag definition missing > > Issue 3421: CosTSInteroperation not specified > > Issue 3422: TranactionPolicyValue definition? > > Issue 3423: TransactionalPolicyComponent definition > > Issue 3424: Policy interrogation API? > > Issue 3425: IORs without policies? > > > > Please let me know if you feel that there are other > > Messaging related OTS issues that should be on the > > list above. > > > > I'd also like ideas on what people would like to see > > resolved with non-Messaging issues as well. Here is > > the beginnings of that list: > > > > (All issues that pass Vote 1) > > Issue 2580: rollback should raise HeuristicMixed, HeuristicHazard, > and HeuristicCommit > > Issue 2931: locality constraints > > > > Blake Date: Wed, 3 May 2000 18:07:38 -0700 From: Blake Biesecker To: ots-rtf@omg.org Cc: messaging-rtf@omg.org Subject: Issue 3343 - Clarification - Transaction Policy and TransactionalObject Message-ID: <20000503180738.A13684@gemstone.com> References: <200004250201.TAA10888@wheel.dcn.davis.ca.us> <200004250201.TAA10888@wheel.dcn.davis.ca.us> <20000425160056.E2548@gemstone.com> <3.0.5.32.20000426150119.00ad2de0@svlhome2.beasys.com> Mime-Version: 1.0 X-Mailer: Mutt 1.0pre4i In-Reply-To: <3.0.5.32.20000426150119.00ad2de0@svlhome2.beasys.com>; from ed.cobb@bea.com on Wed, Apr 26, 2000 at 03:01:19PM -0700 X-Disclaimer: I only speak for myself, unless I expressly indicate otherwise. Content-Type: text/plain; charset=us-ascii X-UIDL: C[P!!@ec!!`A(e9X01!! I've pasted the last discussion I could find on TransactionalObject below (It was part of the 3425 discussion). Without a proposal to actually add TransactionalObject back into the OTS spec with a statement that it is there only for backward compatibility and is a deprecated interface, TransactionalObject will be removed from the spec by the Messaging changes in 2.4. Is anyone interested writing up a formal proposal to add it back in so that we can vote on the issue? (I'll need it very soon.) Without a vote, the fallback position is that vendors will be responsible for adding this interface to their products if they are interested in backward compatibility. Blake On Wed, Apr 26, 2000 at 03:01:19PM -0700, Edward Cobb wrote: > Comments included below. > > At 04:00 PM 4/25/00 -0700, Blake Biesecker wrote: > >On Mon, Apr 24, 2000 at 07:01:51PM -0700, Jeffrey Mischkinsky wrote: > >> 'Michi Henning' writes: > >> > > >> > > As for 2, I'm leaning towards making a clean break and just > >> > > eliminating TransactionalObject from the spec. OTS vendors > >> > > can deal with adding it to their implementations if their > >> > > customers need backward compatability. This seems to be what > >> > > was intended when messaging removed it in the first place. > >> > > >> > We could rev the entire OTS module with a #pragma version statement and > >> > remove TransactionalObject from the new version. This would make sure > >> > that type clashes are at least detectable. The price is that old clients > >> > and new servers clients couldn't interoperate. > >> > > >> > Otherwise, I'd be in favour of leaving TransactionalObject in for now > >> > and deprecating it. We could remove it in a year's time or so, when > >> > the next RTF is in progress. > >> I'd have to check the details of the messaging spec. But i'm not sure > >> that is an option. > >> > >> If the messaging spec, which is a fully adopted, etc., said take it out, > >> then it goes out. If it says deprecate, then it gets deprecated. > >> > >> If it is silent, then we get to decide. > >> > The messaging spec said to take it out, so the base document I sent you > relects what was adopted for messaging and does not include it. We (the OTS > RTF) can choose to put it back as a response to the issue raised by Tom > Freund of IBM. > > >> But given that its now a good long time (> 2 yrs i think) since it was > adopted, > >> people have had plenty of time. > >> > >> jeff > >> Date: Thu, 4 May 2000 11:49:27 +1000 (EST) From: Michi Henning To: Blake Biesecker cc: ots-rtf@omg.org, messaging-rtf@omg.org Subject: Re: Issue 3343 - Clarification - Transaction Policy and TransactionalObject In-Reply-To: <20000503180738.A13684@gemstone.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: f;(!!$"Ae9H$4e9 Without a vote, the fallback position is that vendors will > be responsible for adding this interface to their products > if they are interested in backward compatibility. I believe we are likely to vote that vendors can't just add stuff to CORBA- defined modules. Even if we don't officially outlaw such a thing, I think it's in extrememly bad taste to hack around in standard modules with vendor-specific extensions. Better to make a decision and stick with it. I'm prepared to leave TransactionalObject in the spec and deprecate it, provided that no other part of the IDL is changed. If we change any of the OTS 1.0/1.1 IDL, we might as well remove TransactionalObject too, because then the IDLs will be incompatible anyway. Looking through the changes made by messaging, I notice that: Synchronization : TransactionalObject { // ... }; was changed to: Synchronization { // ... }; This is a no-no, because it changes the IDL of an existing interface. However, I think we can get away with this in this particular case because TransactionalObject is an empty interface... I'd like opinions on this from other people though. Should we add a version pragma to Synchronization? For now, here is a proposal: Modify the text in section 10.3.10 as follows: Replace the first paragraph with: The TransactionalObject interface is a remnant of previous versions of this specification and is no longer used. It is retained here only for backward compatibility with OTS 1.0 and OTS 1.1. [ Box showing interface TransactionalObject {}; ] Cheers, Michi. -- Michi Henning +61 7 3891 5744 Object Oriented Concepts +61 4 1118 2700 (mobile) Suite 4, 904 Stanley St +61 7 3891 5009 (fax) East Brisbane 4169 michi@ooc.com.au AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html From: "Bernard Normier" To: "Michi Henning" , "Blake Biesecker" Cc: , References: Subject: Re: Issue 3343 - Clarification - Transaction Policy and TransactionalObject Date: Wed, 3 May 2000 22:20:36 -0400 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Content-Type: text X-UIDL: DlF!!2nJ!!LVFe9?X5!! I agree with Michi: let's keep the deprecated TransactionalObject and update Synchronization. Cheers, Bernard ----- Original Message ----- From: "Michi Henning" To: "Blake Biesecker" Cc: ; Sent: Wednesday, May 03, 2000 9:49 PM Subject: Re: Issue 3343 - Clarification - Transaction Policy and TransactionalObject > On Wed, 3 May 2000, Blake Biesecker wrote: > > > Without a vote, the fallback position is that vendors will > > be responsible for adding this interface to their products > > if they are interested in backward compatibility. > > I believe we are likely to vote that vendors can't just add stuff to >CORBA- > defined modules. Even if we don't officially outlaw such a thing, I >think > it's in extrememly bad taste to hack around in standard modules with > vendor-specific extensions. Better to make a decision and stick with >it. > > I'm prepared to leave TransactionalObject in the spec and deprecate >it, > provided that no other part of the IDL is changed. If we change any > of the OTS 1.0/1.1 IDL, we might as well remove TransactionalObject >too, > because then the IDLs will be incompatible anyway. > > Looking through the changes made by messaging, I notice that: > > Synchronization : TransactionalObject { > // ... > }; > > was changed to: > > Synchronization { > // ... > }; > > This is a no-no, because it changes the IDL of an existing >interface. > However, I think we can get away with this in this particular case >because > TransactionalObject is an empty interface... I'd like opinions on >this > from other people though. Should we add a version pragma to >Synchronization? > > For now, here is a proposal: > > Modify the text in section 10.3.10 as follows: > > Replace the first paragraph with: > > The TransactionalObject interface is a remnant of previous versions > of this specification and is no longer used. It is retained here > only for backward compatibility with OTS 1.0 and OTS 1.1. > > [ Box showing > > interface TransactionalObject {}; > > ] > > Cheers, > > Michi. > > -- > Michi Henning +61 7 3891 5744 > Object Oriented Concepts +61 4 1118 2700 (mobile) > Suite 4, 904 Stanley St +61 7 3891 5009 (fax) > East Brisbane 4169 michi@ooc.com.au > AUSTRALIA >http://www.ooc.com.au/staff/michi-henning.html > From: "Mark Little" To: "Michi Henning" , "Blake Biesecker" Cc: , References: Subject: Re: Issue 3343 - Clarification - Transaction Policy and TransactionalObject Date: Thu, 4 May 2000 09:19:55 +0100 Organization: Newcastle University MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Content-Type: text/plain; charset="iso-8859-1" X-UIDL: 7?5!!-*:e98=0!!Ed8e9 ----- Original Message ----- > Modify the text in section 10.3.10 as follows: > > Replace the first paragraph with: > > The TransactionalObject interface is a remnant of previous versions > of this specification and is no longer used. It is retained here > only for backward compatibility with OTS 1.0 and OTS 1.1. > > [ Box showing > > interface TransactionalObject {}; > > ] I would agree with the text, assuming that TO is still in the CosTransactions module. Mark. ----------------------------------------------------------------------- SENDER : Dr. Mark Little, Arjuna Project, Distributed Systems Research. PHONE : +44 191 222 8066, FAX : +44 191 222 8232 POST : Department of Computing Science, University of Newcastle upon Tyne, UK, NE1 7RU EMAIL : M.C.Little@newcastle.ac.uk Date: Thu, 4 May 2000 20:00:50 +1000 (EST) From: Michi Henning To: Mark Little cc: Blake Biesecker , ots-rtf@omg.org, messaging-rtf@omg.org Subject: Re: Issue 3343 - Clarification - Transaction Policy and TransactionalObject In-Reply-To: <009c01bfb5a1$878e3830$6e96f080@ncl.ac.uk> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: $%M!!5G;!!YRUd9^I3!! On Thu, 4 May 2000, Mark Little wrote: > I would agree with the text, assuming that TO is still in the > CosTransactions module. Yes, that was the intent, of course. Cheers, Michi. -- Michi Henning +61 7 3891 5744 Object Oriented Concepts +61 4 1118 2700 (mobile) Suite 4, 904 Stanley St +61 7 3891 5009 (fax) East Brisbane 4169 michi@ooc.com.au AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html Date: Thu, 4 May 2000 15:40:49 -0700 From: Blake Biesecker To: ots-rtf@omg.org Subject: Issue 3343 - a proposal - Clarification - Transaction Policy and TransactionalObject Message-ID: <20000504154049.D14264@gemstone.com> Mime-Version: 1.0 X-Mailer: Mutt 1.0pre4i X-Disclaimer: I only speak for myself, unless I expressly indicate otherwise. Content-Type: text/plain; charset=us-ascii X-UIDL: 74R!!eIA!!Y2Ge9S$A!! [I got the issue number in the subject line wrong in the previous email.] Here is a complet proposal for Issue 3343. Please let me know if you see any glaring mistakes or if you think it should be changed. Blake Issue 3343: Clarification - Transaction Policy (ots-rtf) Source: International Business Machines (Mr. Thomas Freund, tjfreund@uk.ibm.com) Nature: Clarification Severity: Summary: Since the updates for TransactionPolicy remove all references to the TransactionalObject Interface how is backward compatibility addressed. As existing BOA/TransactionalObject implementations will continue to exist how do we expect these to interact with the proposed POA/Policy-based implementations. Resolution: Instead of completely removing the TransactionalObject interface, it will instead be deprecated with a note saying that it is in the CosTransactions module only for backward compatibility with OTS 1.0 and 1.1. The Synchronization interface will, however, no longer inherit from TransactionalObject. Revised Text: Modify the text in section 10.3.10 called "TransactionalObject Interface" from OTS 1.1 as follows: Replace the first paragraph with: The TransactionalObject interface is a remnant of previous versions of this specification and is no longer used. It is retained here only for backward compatibility with OTS 1.0 and OTS 1.1. [ Box showing interface TransactionalObject {}; ] The above is to be done instead of removing that section. Adding this section back to the specification will mean that the following sections will need to be renumbered: Renumber the section called "Transaction Policy" (added by Messaging) from 10.3.10 to 10.3.11. Renumber the section called "Creating Transactional Object References" (added by Messaging) from 10.3.11 to 10.3.12. Add these two line to the CosTransactions module in section 10.6: // TransactionalObject has been deprecated. See 10.3.10. interface TransactionalObject {}; Actions taken: February 22, 2000: received issue X-Sender: ecobb@svlhome2.beasys.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Fri, 05 May 2000 08:16:45 -0700 To: Michi Henning , Blake Biesecker From: Edward Cobb Subject: Re: Issue 3343 - Clarification - Transaction Policy and TransactionalObject Cc: ots-rtf@omg.org, messaging-rtf@omg.org In-Reply-To: References: <20000503180738.A13684@gemstone.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-UIDL: F;On Wed, 3 May 2000, Blake Biesecker wrote: > >> Without a vote, the fallback position is that vendors will >> be responsible for adding this interface to their products >> if they are interested in backward compatibility. > >I believe we are likely to vote that vendors can't just add stuff to CORBA- >defined modules. Even if we don't officially outlaw such a thing, I think >it's in extrememly bad taste to hack around in standard modules with >vendor-specific extensions. Better to make a decision and stick with it. > >I'm prepared to leave TransactionalObject in the spec and deprecate it, >provided that no other part of the IDL is changed. If we change any >of the OTS 1.0/1.1 IDL, we might as well remove TransactionalObject too, >because then the IDLs will be incompatible anyway. > >Looking through the changes made by messaging, I notice that: > > Synchronization : TransactionalObject { > // ... > }; > >was changed to: > > Synchronization { > // ... > }; > >This is a no-no, because it changes the IDL of an existing interface. >However, I think we can get away with this in this particular case because >TransactionalObject is an empty interface... I'd like opinions on this >from other people though. Should we add a version pragma to Synchronization? > >For now, here is a proposal: > >Modify the text in section 10.3.10 as follows: > > Replace the first paragraph with: > > The TransactionalObject interface is a remnant of previous versions > of this specification and is no longer used. It is retained here > only for backward compatibility with OTS 1.0 and OTS 1.1. > > [ Box showing > > interface TransactionalObject {}; > > ] > > Cheers, > > Michi. > >-- >Michi Henning +61 7 3891 5744 >Object Oriented Concepts +61 4 1118 2700 (mobile) >Suite 4, 904 Stanley St +61 7 3891 5009 (fax) >East Brisbane 4169 michi@ooc.com.au >AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html > > > ************************************************************** Ed Cobb, Director, Advanced Technology & Standards BEA Systems, Inc., 2315 North First St., San Jose, CA 95131 Tel: 408-570-8264 / Fax: 408-570-8942 E-mail: ed.cobb@beasys.com ************************************************************** Date: Mon, 08 May 2000 14:30:23 -0700 From: Ram Jeyaraman Organization: JavaSoft, Sun Microsystems Inc. X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Edward Cobb CC: Michi Henning , Blake Biesecker , ots-rtf@omg.org, messaging-rtf@omg.org Subject: Re: Issue 3343 - Clarification - Transaction Policy andTransactionalObject References: <20000503180738.A13684@gemstone.com> <3.0.5.32.20000505081645.0083c750@svlhome2.beasys.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: A > I'm happy to leave TransactionalObject in the spec as Michi proposes. > Maybe that allows us to leave the inheritance for Synchronization as well. > Comments? Date: Mon, 8 May 2000 14:59:38 -0700 From: Blake Biesecker To: Ram Jeyaraman Cc: Edward Cobb , Michi Henning , ots-rtf@omg.org, messaging-rtf@omg.org Subject: Re: Issue 3343 - Clarification - Transaction Policy andTransactionalObject Message-ID: <20000508145938.C23389@gemstone.com> References: <20000503180738.A13684@gemstone.com> <3.0.5.32.20000505081645.0083c750@svlhome2.beasys.com> <391731EF.8A63804A@eng.sun.com> Mime-Version: 1.0 X-Mailer: Mutt 1.0pre4i In-Reply-To: <391731EF.8A63804A@eng.sun.com>; from Ram.Jeyaraman@eng.sun.com on Mon, May 08, 2000 at 02:30:23PM -0700 X-Disclaimer: I only speak for myself, unless I expressly indicate otherwise. Content-Type: text/plain; charset=us-ascii X-UIDL: GRPd9\'&!!0<)e9,_0e9 The current proposal for this issue is pasted below. How are you proposing it be changed? Blake On Mon, May 08, 2000 at 02:30:23PM -0700, Ram Jeyaraman wrote: > That is the right. Since all the legacy (OTS 1.1) apps would expect that the before_completion () > calls have a transaction context to flush out the cached data, if any. > > But as Michi stated earlier, we should mark the inheritance such that future apps know it shou ld > rather use a TransactionPolicy for the Sychronization object instead of TransactionObject > inheritance. And the OTS spec should specify the TransactionPolicy of "Allows_Shared" or > "Requires_shared" for the Synchronization object. > > Ram > > Edward Cobb wrote: > > > > I'm happy to leave TransactionalObject in the spec as Michi proposes. > > Maybe that allows us to leave the inheritance for Synchronization as well. > > Comments? > > ---------------------------------------------------------------- Issue 3343: Clarification - Transaction Policy (ots-rtf) Source: International Business Machines (Mr. Thomas Freund, tjfreund@uk.ibm.com) Nature: Clarification Severity: Summary: Since the updates for TransactionPolicy remove all references to the TransactionalObject Interface how is backward compatibility addressed. As existing BOA/TransactionalObject implementations will continue to exist how do we expect these to interact with the proposed POA/Policy-based implementations. Resolution: Instead of completely removing the TransactionalObject interface, it will instead be deprecated with a note saying that it is in the CosTransactions module only for backward compatibility with OTS 1.0 and 1.1. The Synchronization interface will, however, no longer inherit from TransactionalObject. Revised Text: Modify the text in section 10.3.10 as follows: Replace the first paragraph with: The TransactionalObject interface is a remnant of previous versions of this specification and is no longer used. It is retained here only for backward compatibility with OTS 1.0 and OTS 1.1. [ Box showing interface TransactionalObject {}; ] The above is to be done instead of removing that section. Adding this section back to the specification will mean that the following sections will need to be renumbered: Renumber the section called "Transaction Policy" (added by Messaging) from 10.3.10 to 10.3.11. Renumber the section called "Creating Transactional Object References" (added by Messaging) from 10.3.11 to 10.3.12. Add these two lines to the CosTransactions module in section 10.6: // TransactionalObject has been deprecated. See 10.3.10. interface TransactionalObject {}; Actions taken: February 22, 2000: received issue ---------------------------------------------------------------- Date: Mon, 08 May 2000 16:41:43 -0700 From: Ram Jeyaraman Organization: JavaSoft, Sun Microsystems Inc. X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Blake Biesecker CC: Ram Jeyaraman , Edward Cobb , Michi Henning , ots-rtf@omg.org, messaging-rtf@omg.org Subject: Re: Issue 3343 - Clarification - Transaction Policy andTransactionalObject References: <20000503180738.A13684@gemstone.com> <3.0.5.32.20000505081645.0083c750@svlhome2.beasys.com> <391731EF.8A63804A@eng.sun.com> <20000508145938.C23389@gemstone.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: p>%!!+`De94(Wd9-4[d9 Blake, Please find attached the updated resolution, thanks Ram ---> Resolution BEGIN Modify the Synchronization interface definition in Section 10.3.8 as follows: // TransactionalObject has been deprecated. See 10.3.10. // Use a TransactionPolicyValue of "REQUIRES_SHARED" to // indicate transactionality. interface Synchronization : TransactionalObject { void before_completion(); void after_completion(in Status status); }; The above change has to be reflected in the CosTransactions module 10.6. Modify the text in section 10.3.10 as follows: Replace the first paragraph with: The TransactionalObject interface is a remnant of previous versions of this specification and is no longer used. It is retained here only for backward compatibility with OTS 1.0 and OTS 1.1. [ Box showing interface TransactionalObject {}; ] The above is to be done instead of removing that section. Adding this section back to the specification will mean that the following sections will need to be renumbered: Renumber the section called "Transaction Policy" (added by Messaging) from 10.3.10 to 10.3.11. Renumber the section called "Creating Transactional Object References" (added by Messaging) from 10.3.11 to 10.3.12. Add these two lines to the CosTransactions module in section 10.6: // TransactionalObject has been deprecated. See 10.3.10. interface TransactionalObject {}; ----> Resolution END Blake Biesecker wrote: > > The current proposal for this issue is pasted below. > How are you proposing it be changed? > > Blake > > On Mon, May 08, 2000 at 02:30:23PM -0700, Ram Jeyaraman wrote: > > That is the right. Since all the legacy (OTS 1.1) apps would expect that the before_completion > () > > calls have a transaction context to flush out the cached data, if any. > > > > But as Michi stated earlier, we should mark the inheritance such that future apps know it shou > ld > > rather use a TransactionPolicy for the Sychronization object instead of TransactionObject > > inheritance. And the OTS spec should specify the TransactionPolicy of "Allows_Shared" or > > "Requires_shared" for the Synchronization object. > > > > Ram > > > > Edward Cobb wrote: > > > > > > I'm happy to leave TransactionalObject in the spec as Michi proposes. > > > Maybe that allows us to leave the inheritance for Synchronization as well. > > > Comments? > > > > > ---------------------------------------------------------------- > Issue 3343: Clarification - Transaction Policy (ots-rtf) > > Source: International Business Machines (Mr. Thomas Freund, tjfreund@uk.ibm.com) > > Nature: Clarification > > Severity: > > Summary: Since the updates for TransactionPolicy remove all references to > the TransactionalObject Interface how is backward compatibility addressed. > As existing BOA/TransactionalObject implementations will continue to exist > how do we expect these to interact with the proposed POA/Policy-based > implementations. > > Resolution: Instead of completely removing the TransactionalObject interface, > it will instead be deprecated with a note saying that it is in the > CosTransactions module only for backward compatibility with OTS 1.0 > and 1.1. The Synchronization interface will, however, no longer > inherit from TransactionalObject. > > Revised Text: > > Modify the text in section 10.3.10 as follows: > > Replace the first paragraph with: > > The TransactionalObject interface is a remnant of previous versions > of this specification and is no longer used. It is retained here > only for backward compatibility with OTS 1.0 and OTS 1.1. > > [ Box showing > > interface TransactionalObject {}; > > ] > > The above is to be done instead of removing that section. Adding > this section back to the specification will mean that the following > sections will need to be renumbered: > > Renumber the section called "Transaction Policy" (added by Messaging) > from 10.3.10 to 10.3.11. > > Renumber the section called "Creating Transactional Object References" > (added by Messaging) from 10.3.11 to 10.3.12. > > Add these two lines to the CosTransactions module in section 10.6: > > // TransactionalObject has been deprecated. See 10.3.10. > interface TransactionalObject {}; > > Actions taken: > February 22, 2000: received issue > ---------------------------------------------------------------- Date: Mon, 8 May 2000 18:11:38 -0700 From: Blake Biesecker To: ots-rtf@omg.org Cc: Edward Cobb , Michi Henning , ots-rtf@omg.org, messaging-rtf@omg.org Subject: Re: Issue 3343 - Clarification - Transaction Policy andTransactionalObject Message-ID: <20000508181136.C23764@gemstone.com> References: <20000503180738.A13684@gemstone.com> <3.0.5.32.20000505081645.0083c750@svlhome2.beasys.com> <391731EF.8A63804A@eng.sun.com> <20000508145938.C23389@gemstone.com> <391750B7.CA7D03EC@eng.sun.com> Mime-Version: 1.0 X-Mailer: Mutt 1.0pre4i In-Reply-To: <391750B7.CA7D03EC@eng.sun.com>; from Ram.Jeyaraman@eng.sun.com on Mon, May 08, 2000 at 04:41:43PM -0700 X-Disclaimer: I only speak for myself, unless I expressly indicate otherwise. Content-Type: text/plain; charset=us-ascii X-UIDL: 0#;!!pdPd9+LDe9'4Be9 What is the general consensus on the issue of Synchronization inheriting from TransactionalObject? I don't have a good feeling which way people are leaning and I'd hate for the entire issue to fail over what we do with Synchronization. (I also think that since TransactionalObject is an empty interface, it is probably not as critical that we keep Synchronization inheriting from it.) There seemed to be support for updating Synchronization to not inherit from TransactionalObject as suggested by the Messaging changes. What do other's think about this? Blake On Mon, May 08, 2000 at 04:41:43PM -0700, Ram Jeyaraman wrote: > Blake, > > Please find attached the updated resolution, > > thanks > Ram > > > ---> Resolution BEGIN > > Modify the Synchronization interface definition in Section 10.3.8 as follows: > > // TransactionalObject has been deprecated. See 10.3.10. > // Use a TransactionPolicyValue of "REQUIRES_SHARED" to > // indicate transactionality. > interface Synchronization : TransactionalObject { > void before_completion(); > void after_completion(in Status status); > }; > > The above change has to be reflected in the CosTransactions module 10.6. > > Modify the text in section 10.3.10 as follows: > > Replace the first paragraph with: > > The TransactionalObject interface is a remnant of previous versions > of this specification and is no longer used. It is retained here > only for backward compatibility with OTS 1.0 and OTS 1.1. > > [ Box showing > > interface TransactionalObject {}; > > ] > > The above is to be done instead of removing that section. Adding > this section back to the specification will mean that the following > sections will need to be renumbered: > > Renumber the section called "Transaction Policy" (added by Messaging) > from 10.3.10 to 10.3.11. > > Renumber the section called "Creating Transactional Object References" > (added by Messaging) from 10.3.11 to 10.3.12. > > > Add these two lines to the CosTransactions module in section 10.6: > > // TransactionalObject has been deprecated. See 10.3.10. > interface TransactionalObject {}; > > ----> Resolution END > > Blake Biesecker wrote: > > > > The current proposal for this issue is pasted below. > > How are you proposing it be changed? > > > > Blake > > > > On Mon, May 08, 2000 at 02:30:23PM -0700, Ram Jeyaraman wrote: > > > That is the right. Since all the legacy (OTS 1.1) apps would expect that the before_completion > > () > > > calls have a transaction context to flush out the cached data, if any. > > > > > > But as Michi stated earlier, we should mark the inheritance such that future apps know it shou > > ld > > > rather use a TransactionPolicy for the Sychronization object instead of TransactionObject > > > inheritance. And the OTS spec should specify the TransactionPolicy of "Allows_Shared" or > > > "Requires_shared" for the Synchronization object. > > > > > > Ram > > > > > > Edward Cobb wrote: > > > > > > > > I'm happy to leave TransactionalObject in the spec as Michi proposes. > > > > Maybe that allows us to leave the inheritance for Synchronization as well. > > > > Comments? > > > > > > > > ---------------------------------------------------------------- > > Issue 3343: Clarification - Transaction Policy (ots-rtf) > > > > Source: International Business Machines (Mr. Thomas Freund, tjfreund@uk.ibm.com) > > > > Nature: Clarification > > > > Severity: > > > > Summary: Since the updates for TransactionPolicy remove all references to > > the TransactionalObject Interface how is backward compatibility addressed. > > As existing BOA/TransactionalObject implementations will continue to exist > > how do we expect these to interact with the proposed POA/Policy-based > > implementations. > > > > Resolution: Instead of completely removing the TransactionalObject interface, > > it will instead be deprecated with a note saying that it is in the > > CosTransactions module only for backward compatibility with OTS 1.0 > > and 1.1. The Synchronization interface will, however, no longer > > inherit from TransactionalObject. > > > > Revised Text: > > > > Modify the text in section 10.3.10 as follows: > > > > Replace the first paragraph with: > > > > The TransactionalObject interface is a remnant of previous versions > > of this specification and is no longer used. It is retained here > > only for backward compatibility with OTS 1.0 and OTS 1.1. > > > > [ Box showing > > > > interface TransactionalObject {}; > > > > ] > > > > The above is to be done instead of removing that section. Adding > > this section back to the specification will mean that the following > > sections will need to be renumbered: > > > > Renumber the section called "Transaction Policy" (added by Messaging) > > from 10.3.10 to 10.3.11. > > > > Renumber the section called "Creating Transactional Object References" > > (added by Messaging) from 10.3.11 to 10.3.12. > > > > Add these two lines to the CosTransactions module in section 10.6: > > > > // TransactionalObject has been deprecated. See 10.3.10. > > interface TransactionalObject {}; > > > > Actions taken: > > February 22, 2000: received issue > > ---------------------------------------------------------------- Date: Tue, 9 May 2000 13:19:51 +1000 (EST) From: Michi Henning To: Blake Biesecker cc: ots-rtf@omg.org, Edward Cobb , messaging-rtf@omg.org Subject: Re: Issue 3343 - Clarification - Transaction Policy andTransactionalObject In-Reply-To: <20000508181136.C23764@gemstone.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: P,dd9BJ^!!/Fl!!M>2!! On Mon, 8 May 2000, Blake Biesecker wrote: > What is the general consensus on the issue of Synchronization > inheriting from TransactionalObject? > > I don't have a good feeling which way people are leaning and > I'd hate for the entire issue to fail over what we do with > Synchronization. (I also think that since TransactionalObject > is an empty interface, it is probably not as critical that > we keep Synchronization inheriting from it.) There seemed > to be support for updating Synchronization to not inherit > from TransactionalObject as suggested by the Messaging > changes. > > What do other's think about this? I'd rather avoid IDL changes unless they are absolutely necessary. It seems easiest to simply leave the inheritance. That way, things will work for an OTS 1.1 client. For Synchronization objects implemented with OTS 1.2, the TransactionalObject inheritance doesn't mean anything and I have to make sure that the Synchronization object is created with a transactional POA anyway. Cheers, Michi. From: "Mark Little" To: "Michi Henning" , "Blake Biesecker" Cc: , "Edward Cobb" , References: Subject: Re: Issue 3343 - Clarification - Transaction Policy andTransactionalObject Date: Tue, 9 May 2000 09:03:50 +0100 Organization: Newcastle University MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Content-Type: text/plain; charset="iso-8859-1" X-UIDL: AE>e9cl3!!\)[d90?F!! ----- Original Message ----- > I'd rather avoid IDL changes unless they are absolutely necessary. > It seems easiest to simply leave the inheritance. That way, things > will > work for an OTS 1.1 client. For Synchronization objects implemented > with OTS 1.2, the TransactionalObject inheritance doesn't mean > anything > and I have to make sure that the Synchronization object is created > with a transactional POA anyway. I agree with this approach. Mark. ----------------------------------------------------------------------- SENDER : Dr. Mark Little, Arjuna Project, Distributed Systems Research. PHONE : +44 191 222 8066, FAX : +44 191 222 8232 POST : Department of Computing Science, University of Newcastle upon Tyne, UK, NE1 7RU EMAIL : M.C.Little@newcastle.ac.uk From: "Bernard Normier" To: "Mark Little" , "Michi Henning" , "Blake Biesecker" Cc: , "Edward Cobb" , References: <031f01bfb98d$1c4f9c90$6e96f080@ncl.ac.uk> Subject: Re: Issue 3343 - Clarification - Transaction Policy andTransactionalObject Date: Tue, 9 May 2000 10:27:16 -0400 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Content-Type: text X-UIDL: 6i]d9GT/e9>a_d9W1P!! I also agree with Michi. Bernard ----- Original Message ----- From: "Mark Little" To: "Michi Henning" ; "Blake Biesecker" Cc: ; "Edward Cobb" ; Sent: Tuesday, May 09, 2000 4:03 AM Subject: Re: Issue 3343 - Clarification - Transaction Policy andTransactionalObject > > ----- Original Message ----- > > > I'd rather avoid IDL changes unless they are absolutely necessary. > > It seems easiest to simply leave the inheritance. That way, things will > > work for an OTS 1.1 client. For Synchronization objects implemented > > with OTS 1.2, the TransactionalObject inheritance doesn't mean anything > > and I have to make sure that the Synchronization object is created > > with a transactional POA anyway. > > I agree with this approach. > > Mark. > > ----------------------------------------------------------------------- > SENDER : Dr. Mark Little, Arjuna Project, Distributed Systems Research. > PHONE : +44 191 222 8066, FAX : +44 191 222 8232 > POST : Department of Computing Science, University of Newcastle upon > Tyne, UK, NE1 7RU > EMAIL : M.C.Little@newcastle.ac.uk > > > Date: Tue, 9 May 2000 10:14:25 -0700 From: Blake Biesecker To: ots-rtf@omg.org Cc: ots-rtf@omg.org, Michi Henning , messaging-rtf@omg.org Subject: Re: Issue 3343 - Clarification - Transaction Policy andTransactionalObject Message-ID: <20000509101425.A27765@gemstone.com> References: <391750B7.CA7D03EC@eng.sun.com> <20000503180738.A13684@gemstone.com> <3.0.5.32.20000505081645.0083c750@svlhome2.beasys.com> <391731EF.8A63804A@eng.sun.com> <20000508145938.C23389@gemstone.com> <391750B7.CA7D03EC@eng.sun.com> <20000508181136.C23764@gemstone.com> <3.0.5.32.20000509084545.00b5c100@svlhome2.beasys.com> Mime-Version: 1.0 X-Mailer: Mutt 1.0pre4i In-Reply-To: <3.0.5.32.20000509084545.00b5c100@svlhome2.beasys.com>; from ed.cobb@bea.com on Tue, May 09, 2000 at 08:45:45AM -0700 X-Disclaimer: I only speak for myself, unless I expressly indicate otherwise. Content-Type: text/plain; charset=us-ascii X-UIDL: Sdi!!OYA!!9('e9ieCe9 It looks like there is overwhelming support for retaining the inheritance in the definition of the Synchronization interface. My main concern was that not removing the inheritance would make it more difficult to do later, but as Ed points out, it doesn't hurt anything, so it really doesn't matter if it stays in or not. I'll change the proposal. Blake On Tue, May 09, 2000 at 08:45:45AM -0700, Edward Cobb wrote: > The messaging changes removed TransactionalObject, so there was no choice > but to remove the inheritance in the definition of the Synchronization > interface. Given that we've decided to retain TransactionalObject in the > 1.2 spec, I'd vote for retaining the inheritance on Synchronization since > it avoids versioning the IDL and doesn't hurt anything. It does mean that > the definition of TransactionalObject will probably be with us forever. > > At 06:11 PM 5/8/00 -0700, Blake Biesecker wrote: > >What is the general consensus on the issue of Synchronization > >inheriting from TransactionalObject? > > > >I don't have a good feeling which way people are leaning and > >I'd hate for the entire issue to fail over what we do with > >Synchronization. (I also think that since TransactionalObject > >is an empty interface, it is probably not as critical that > >we keep Synchronization inheriting from it.) There seemed > >to be support for updating Synchronization to not inherit > >from TransactionalObject as suggested by the Messaging > >changes. > > > >What do other's think about this? > > > >Blake > > > >On Mon, May 08, 2000 at 04:41:43PM -0700, Ram Jeyaraman wrote: > >> Blake, > >> > >> Please find attached the updated resolution, > >> > >> thanks > >> Ram > >> > >> > >> ---> Resolution BEGIN > >> > >> Modify the Synchronization interface definition in Section 10.3.8 as > follows: > >> > >> // TransactionalObject has been deprecated. See 10.3.10. > >> // Use a TransactionPolicyValue of "REQUIRES_SHARED" to > >> // indicate transactionality. > >> interface Synchronization : TransactionalObject { > >> void before_completion(); > >> void after_completion(in Status status); > >> }; > >> > >> The above change has to be reflected in the CosTransactions module 10.6. > >> > >> Modify the text in section 10.3.10 as follows: > > >> > > >> Replace the first paragraph with: > > >> > > >> The TransactionalObject interface is a remnant of previous > versions > >> of this specification and is no longer used. It is retained here > > >> only for backward compatibility with OTS 1.0 and OTS 1.1. > > >> > > >> [ Box showing > > >> > > >> interface TransactionalObject {}; > > >> > > >> ] > >> > >> The above is to be done instead of removing that section. Adding > >> this section back to the specification will mean that the following > >> sections will need to be renumbered: > >> > >> Renumber the section called "Transaction Policy" (added by Messaging) > >> from 10.3.10 to 10.3.11. > >> > >> Renumber the section called "Creating Transactional Object References" > >> (added by Messaging) from 10.3.11 to 10.3.12. > >> > >> > >> Add these two lines to the CosTransactions module in section 10.6: > >> > >> // TransactionalObject has been deprecated. See 10.3.10. > >> interface TransactionalObject {}; > >> > >> ----> Resolution END > >> > >> Blake Biesecker wrote: > >> > > >> > The current proposal for this issue is pasted below. > >> > How are you proposing it be changed? > >> > > >> > Blake > >> > > >> > On Mon, May 08, 2000 at 02:30:23PM -0700, Ram Jeyaraman wrote: > >> > > That is the right. Since all the legacy (OTS 1.1) apps would expect > that the before_completion > >> > () > >> > > calls have a transaction context to flush out the cached data, if any. > >> > > > >> > > But as Michi stated earlier, we should mark the inheritance such > that future apps know it shou > >> > ld > >> > > rather use a TransactionPolicy for the Sychronization object instead > of TransactionObject > >> > > inheritance. And the OTS spec should specify the TransactionPolicy > of "Allows_Shared" or > >> > > "Requires_shared" for the Synchronization object. > >> > > > >> > > Ram > >> > > > >> > > Edward Cobb wrote: > >> > > > > >> > > > I'm happy to leave TransactionalObject in the spec as > Michi proposes. > >> > > > Maybe that allows us to leave the inheritance for Synchronization > as well. > >> > > > Comments? > >> > > > > >> > > >> > ---------------------------------------------------------------- > >> > Issue 3343: Clarification - Transaction Policy (ots-rtf) > >> > > >> > Source: International Business Machines (Mr. Thomas Freund, > tjfreund@uk.ibm.com) > >> > > >> > Nature: Clarification > >> > > >> > Severity: > >> > > >> > Summary: Since the updates for TransactionPolicy remove all references to > >> > the TransactionalObject Interface how is backward compatibility > addressed. > >> > As existing BOA/TransactionalObject implementations will continue to > exist > >> > how do we expect these to interact with the proposed POA/Policy-based > >> > implementations. > >> > > >> > Resolution: Instead of completely removing the TransactionalObject > interface, > >> > it will instead be deprecated with a note saying that it is in the > >> > CosTransactions module only for backward compatibility with OTS 1.0 > >> > and 1.1. The Synchronization interface will, however, no longer > >> > inherit from TransactionalObject. > >> > > >> > Revised Text: > >> > > >> > Modify the text in section 10.3.10 as follows: > >> > > >> > Replace the first paragraph with: > >> > > >> > The TransactionalObject interface is a remnant of previous > versions > >> > of this specification and is no longer used. It is retained here > >> > only for backward compatibility with OTS 1.0 and OTS 1.1. > >> > > >> > [ Box showing > >> > > >> > interface TransactionalObject {}; > >> > > >> > ] > >> > > >> > The above is to be done instead of removing that section. Adding > >> > this section back to the specification will mean that the following > >> > sections will need to be renumbered: > >> > > >> > Renumber the section called "Transaction Policy" (added by Messaging) > >> > from 10.3.10 to 10.3.11. > >> > > >> > Renumber the section called "Creating Transactional Object References" > >> > (added by Messaging) from 10.3.11 to 10.3.12. > >> > > >> > Add these two lines to the CosTransactions module in section 10.6: > >> > > >> > // TransactionalObject has been deprecated. See 10.3.10. > >> > interface TransactionalObject {}; > >> > > >> > Actions taken: > >> > February 22, 2000: received issue > >> > ---------------------------------------------------------------- > > > > > ************************************************************** > Ed Cobb, Director, Advanced Technology & Standards > BEA Systems, Inc., 2315 North First St., San Jose, CA 95131 > Tel: 408-570-8264 / Fax: 408-570-8942 > E-mail: ed.cobb@beasys.com > ************************************************************** Date: Wed, 10 May 2000 08:56:15 +1000 (EST) From: Michi Henning To: Edward Cobb cc: Blake Biesecker , ots-rtf@omg.org, messaging-rtf@omg.org Subject: Re: Issue 3343 - Clarification - Transaction Policy andTransactionalObject In-Reply-To: <3.0.5.32.20000509084545.00b5c100@svlhome2.beasys.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: MpZ!!Qdl!!%SAe9&8S!! On Tue, 9 May 2000, Edward Cobb wrote: > The messaging changes removed TransactionalObject, so there was no choice > but to remove the inheritance in the definition of the Synchronization > interface. Given that we've decided to retain TransactionalObject in the > 1.2 spec, I'd vote for retaining the inheritance on Synchronization since > it avoids versioning the IDL and doesn't hurt anything. It does mean that > the definition of TransactionalObject will probably be with us forever. I agree. It's not pretty, but better than the alternatives. Cheers, Michi. -- Michi Henning +61 7 3891 5744 Object Oriented Concepts +61 4 1118 2700 (mobile) Suite 4, 904 Stanley St +61 7 3891 5009 (fax) East Brisbane 4169 michi@ooc.com.au AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html Date: Fri, 26 May 2000 18:49:09 -0700 From: Ram Jeyaraman Organization: JavaSoft, Sun Microsystems Inc. X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Blake Biesecker CC: ots-rtf@omg.org Subject: Re: Vote 2 - html file attached References: <20000526092125.A15341@gemstone.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: &nHe96f$e9plV!!ic/e9 Blake, Sun Microsystems Inc. votes YES on resolutions to all the issues listed for Vote 2. A minor correction to issue 3343 which adds the following text to the Synchronization interface definition. Since the after_completion method need not be called with a transaction context, SUPPORTS_SHARED would be an ideal choice instead of REQUIRES_SHARED. ----------------------------- PROPOSED TEXT --------- // TransactionalObject has been deprecated. See 10.3.10. // Use a TransactionPolicyValue of "REQUIRES_SHARED" to // indicate transactionality. interface Synchronization : TransactionalObject { void before_completion(); void after_completion(in Status status); }; -----------------------------> END thanks Ram Blake Biesecker wrote: > > It looks like there are some problmes with the OMG > site, so I am sending out a copy of the html file > I had posted on the web site. > > Hopefully the OMG website will be available soon, > but this file will allow you to read the proposals > for vote 2 until it comes up again. > > Let me know if you have any questions. > > Blake > > ---------------------------------------------------------------------------------------------------- > > otsrtf2000Vote2.htmlName: otsrtf2000Vote2.html > Type: Hypertext Markup Language (text/html) Date: Thu, 08 Jun 2000 09:27:42 -0700 From: Ram Jeyaraman Organization: JavaSoft, Sun Microsystems Inc. X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Blake Biesecker CC: ots-rtf@omg.org Subject: Re: Editorial change to issue 1850 References: <20000525132359.F3636@gemstone.com> <393D2A69.AAC5C907@fpk.hp.com> <20000608070505.A19037@gemstone.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: 9bS!!NmCe9_@D!!@4i!! also are we planning to include this change for issue 3343 ? A minor correction to issue 3343 which adds the following text to the Synchronization interface definition. Since the after_completion method need not be called with a transaction context, ALLOWS_SHARED would be an ideal choice instead of REQUIRES_SHARED. ----------------------------- PROPOSED TEXT --------- // TransactionalObject has been deprecated. See 10.3.10. // Use a TransactionPolicyValue of "ALLOWS_SHARED" to // indicate transactionality. interface Synchronization : TransactionalObject { void before_completion(); void after_completion(in Status status); }; -----------------------------> END thanks Ram Blake Biesecker wrote: > > On Tue, Jun 06, 2000 at 12:44:25PM -0400, Jishnu Mukerji wrote: > [snip] > > > > One minor comment on the resolution for Issue 1850.... Just for > > completeness's sake shouldn't we state that the unsigned long value > > returned by the get_timeout operation represents the timeout period in > > number of seconds (at least that is what I gather it is from the > > resolution of issue 1851)? > > > > Regards, > > > > Jishnu. > > This is to officially announce that I am planning on making the > clarification Jishnu describes above as an editorial change. If > anyone disagrees with this change, please speak up. If there is > even one objection, I will open a new issue and we can vote on the > change. The deadline for objecting will be Thursday, June 15th at > 6:00 PM. Objections received after that will be dealt with by > opening a new issue to reverse the editorial change. > > Please let me know if you have any questions or concerns regarding > this change. > > Blake Date: Thu, 8 Jun 2000 15:22:26 -0700 From: Blake Biesecker To: Ram Jeyaraman Cc: ots-rtf@omg.org Subject: Editorial change to issue 3343 Message-ID: <20000608152226.A19840@gemstone.com> References: <20000525132359.F3636@gemstone.com> <393D2A69.AAC5C907@fpk.hp.com> <20000608070505.A19037@gemstone.com> <393FC97E.309FFD3@eng.sun.com> Mime-Version: 1.0 X-Mailer: Mutt 1.0pre4i In-Reply-To: <393FC97E.309FFD3@eng.sun.com>; from Ram.Jeyaraman@eng.sun.com on Thu, Jun 08, 2000 at 09:27:42AM -0700 X-Disclaimer: I only speak for myself, unless I expressly indicate otherwise. Content-Type: text/plain; charset=us-ascii X-UIDL: VG(!!peEe9@@ed9>PZd9 Actually, since the status of the Messaging changes is a state of flux, I think we should remove the text about TransactionPolicyValue for now. (More likely than not ALLOWS_SHARED will be changed to SUPPORTS_SHARED, for example.) My intention was to remove any text that relied on Messaging changes. So unless I get objections, I going to edit the last two lines of the comment out. We can then add appropriate text later once we've worked out a proposal for fixing the Messaging changes. Objections? Like with issue 1850, if I get any objections to this edit, I'll open an issue to get the change made. The objection deadline is June 15th at 6:00 PM Pacific time. Blake On Thu, Jun 08, 2000 at 09:27:42AM -0700, Ram Jeyaraman wrote: > also are we planning to include this change for issue 3343 ? > > A minor correction to issue 3343 which adds the following text to the Synchronization interface > definition. Since the after_completion method need not be called with a transaction context, > ALLOWS_SHARED would be an ideal choice instead of REQUIRES_SHARED. > > ----------------------------- PROPOSED TEXT --------- > // TransactionalObject has been deprecated. See 10.3.10. > // Use a TransactionPolicyValue of "ALLOWS_SHARED" to > // indicate transactionality. > interface Synchronization : TransactionalObject { > void before_completion(); > void after_completion(in Status status); > }; > -----------------------------> END > > thanks > Ram > > > > Blake Biesecker wrote: > > > > On Tue, Jun 06, 2000 at 12:44:25PM -0400, Jishnu Mukerji wrote: > > [snip] > > > > > > One minor comment on the resolution for Issue 1850.... Just for > > > completeness's sake shouldn't we state that the unsigned long value > > > returned by the get_timeout operation represents the timeout period in > > > number of seconds (at least that is what I gather it is from the > > > resolution of issue 1851)? > > > > > > Regards, > > > > > > Jishnu. > > > > This is to officially announce that I am planning on making the > > clarification Jishnu describes above as an editorial change. If > > anyone disagrees with this change, please speak up. If there is > > even one objection, I will open a new issue and we can vote on the > > change. The deadline for objecting will be Thursday, June 15th at > > 6:00 PM. Objections received after that will be dealt with by > > opening a new issue to reverse the editorial change. > > > > Please let me know if you have any questions or concerns regarding > > this change. > > > > Blake From: Peter Furniss To: Blake Biesecker , "'Ram Jeyaraman'" Cc: "ots-rtf@omg.org" Subject: issue 3343 (in vote 2) (was RE: Editorial change to issue 1850) Date: Thu, 8 Jun 2000 23:35:01 +0100 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by emerald.omg.org id SAA05383 Content-Type: text/plain; charset="us-ascii" X-UIDL: \^S!!]3:e9*Ih!!R'g!! Ram Jeyaraman sent (the message copied at the end) I don't think changing "REQUIRES_SHARED" to "ALLOWS_SHARED" on Synchronization is that minor. But it made me look again at the text, and I strengthen my earlier question. This is really a separate issue from 3343, but I now believe the original vote2 text for 3343 is wrong, so I would like to change the Open-IT vote on 3343 to NO. ( I think I've got an hour or two left if I've got the timezones right :-) Apologies for raising this late Why was the Synchronization interface derived from TO, and will now be expected to have an implicit context supplied when called, whether before or after? It is a completely different meaning to context propagation to that used by application interfaces. None of the rest of the OTS interfaces themselves use it to identify which transaction they are talking about - they all (apparently - see issue 3671) have one-off object incarnations that are "implicitly associated with a single transaction". Without supporting text (unless it's lurking in there and I haven't noticed), it would even seem to be possible to invoke Synchronization operations with a context for a *different* transaction from the one they are involved with (I can't imagine why anyone would). But in the case of after_completion, with checking, it would be illegal to propagate the original context anyway. This all seems so odd I wonder if I've grossly misunderstood something. Synchronization is always a bit peculiar anyway (though I've recently found a really neat application-related use for it) Peter Furniss -------------------------------------- Associate Open-IT Limited 58 Alexandra Crescent, Bromley, Kent BR1 4EX, UK Phone & fax : +44 (0) 20 7729 9012) Email : P.Furniss@mailbox.ulcc.ac.uk Ram Jeyaraman sent : > also are we planning to include this change for issue 3343 ? > > A minor correction to issue 3343 which adds the following text to > the Synchronization interface > definition. Since the after_completion method need not be called > with a transaction context, > ALLOWS_SHARED would be an ideal choice instead of REQUIRES_SHARED. > > ----------------------------- PROPOSED TEXT --------- > // TransactionalObject has been deprecated. See 10.3.10. > // Use a TransactionPolicyValue of "ALLOWS_SHARED" to > // indicate transactionality. > interface Synchronization : TransactionalObject { > void before_completion(); > void after_completion(in Status status); > }; > -----------------------------> END > > thanks > Ram > > > > Blake Biesecker wrote: > > > > On Tue, Jun 06, 2000 at 12:44:25PM -0400, Jishnu Mukerji wrote: > > [snip] > > > > > > One minor comment on the resolution for Issue 1850.... Just for > > > completeness's sake shouldn't we state that the unsigned long > value > > > returned by the get_timeout operation represents the timeout > period in > > > number of seconds (at least that is what I gather it is from the > > > resolution of issue 1851)? > > > > > > Regards, > > > > > > Jishnu. > > > > This is to officially announce that I am planning on making the > > clarification Jishnu describes above as an editorial change. If > > anyone disagrees with this change, please speak up. If there is > > even one objection, I will open a new issue and we can vote on the > > change. The deadline for objecting will be Thursday, June 15th at > > 6:00 PM. Objections received after that will be dealt with by > > opening a new issue to reverse the editorial change. > > > > Please let me know if you have any questions or concerns regarding > > this change. > > > > Blake > From: "Eric Newcomer" To: "Blake Biesecker" , "Ram Jeyaraman" Cc: Subject: RE: Editorial change to issue 3343 Date: Thu, 8 Jun 2000 18:37:19 -0400 Message-ID: MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <20000608152226.A19840@gemstone.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Content-Type: text/plain; charset="us-ascii" X-UIDL: L([d9H;Z!!>&m!!2C_!! Sounds ok. Eric Newcomer IONA Technologies 200 West Street Waltham, MA 02451 Tel: +1 781 902 8366 Fax: +1 781 902 8001 -----Original Message----- From: Blake Biesecker [mailto:blakeb@gemstone.com] Sent: Thursday, June 08, 2000 6:22 PM To: Ram Jeyaraman Cc: ots-rtf@omg.org Subject: Editorial change to issue 3343 Actually, since the status of the Messaging changes is a state of flux, I think we should remove the text about TransactionPolicyValue for now. (More likely than not ALLOWS_SHARED will be changed to SUPPORTS_SHARED, for example.) My intention was to remove any text that relied on Messaging changes. So unless I get objections, I going to edit the last two lines of the comment out. We can then add appropriate text later once we've worked out a proposal for fixing the Messaging changes. Objections? Like with issue 1850, if I get any objections to this edit, I'll open an issue to get the change made. The objection deadline is June 15th at 6:00 PM Pacific time. Blake On Thu, Jun 08, 2000 at 09:27:42AM -0700, Ram Jeyaraman wrote: > also are we planning to include this change for issue 3343 ? > > A minor correction to issue 3343 which adds the following text to the Synchronization interface > definition. Since the after_completion method need not be called with a transaction context, > ALLOWS_SHARED would be an ideal choice instead of REQUIRES_SHARED. > > ----------------------------- PROPOSED TEXT --------- > // TransactionalObject has been deprecated. See 10.3.10. > // Use a TransactionPolicyValue of "ALLOWS_SHARED" to > // indicate transactionality. > interface Synchronization : TransactionalObject { > void before_completion(); > void after_completion(in Status status); > }; > -----------------------------> END > > thanks > Ram > > > > Blake Biesecker wrote: > > > > On Tue, Jun 06, 2000 at 12:44:25PM -0400, Jishnu Mukerji wrote: > > [snip] > > > > > > One minor comment on the resolution for Issue 1850.... Just for > > > completeness's sake shouldn't we state that the unsigned long value > > > returned by the get_timeout operation represents the timeout period in > > > number of seconds (at least that is what I gather it is from the > > > resolution of issue 1851)? > > > > > > Regards, > > > > > > Jishnu. > > > > This is to officially announce that I am planning on making the > > clarification Jishnu describes above as an editorial change. If > > anyone disagrees with this change, please speak up. If there is > > even one objection, I will open a new issue and we can vote on the > > change. The deadline for objecting will be Thursday, June 15th at > > 6:00 PM. Objections received after that will be dealt with by > > opening a new issue to reverse the editorial change. > > > > Please let me know if you have any questions or concerns regarding > > this change. > > > > Blake X-Sender: ecobb@svlhome2.beasys.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Thu, 08 Jun 2000 16:22:16 -0700 To: Peter Furniss From: Edward Cobb Subject: Re: issue 3343 (in vote 2) (was RE: Editorial change to issue 1850) Cc: ots-rtf@omg.org In-Reply-To: <01BFD1A2.392FBC00@B193.ds.ulcc.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-UIDL: 5WOe9@;Q!!7]9!!@c3e9 A historical note about Synchronization. The intended use of synchronization (and the one adopted by both EJB and CCM) is to provide a signal from the transaction coordinator to flush the object cache back to the database so the DB can manage transaction durability. That means that the implementation will ultimately have to execute an SQL call, which with an XA DB manager requires thread-specific transactions. This has been reworked some with JDBC and PSS since the XA standard doesn't really support multi-threading in an unambiguous way, so this might be no longer necessary. But somebody will have to associate the proper transaction with the thread which will write back the cache. At 11:35 PM 6/8/00 +0100, you wrote: >Ram Jeyaraman sent (the message copied at the end) > > >I don't think changing "REQUIRES_SHARED" to "ALLOWS_SHARED" on Synchronization is that minor. But it made me look again at the text, and I strengthen my earlier question. This is really a separate issue from 3343, but I now believe the original vote2 text for 3343 is wrong, so I would like to change the Open-IT vote on 3343 to NO. ( I think I've got an hour or two left if I've got the timezones right :-) >Apologies for raising this late > >Why was the Synchronization interface derived from TO, and will now be expected to have an implicit context supplied when called, whether before or after? It is a completely different meaning to context propagation to that used by application interfaces. None of the rest of the OTS interfaces themselves use it to identify which transaction they are talking about - they all (apparently - see issue 3671) have one-off object incarnations that are "implicitly associated with a single transaction". Without supporting text (unless it's lurking in there and I haven't noticed), it would even seem to be possible to invoke Synchronization operations with a context for a *different* transaction from the one they are involved with (I can't imagine why anyone would). > >But in the case of after_completion, with checking, it would be illegal to propagate the original context anyway. > >This all seems so odd I wonder if I've grossly misunderstood something. Synchronization is always a bit peculiar anyway (though I've recently found a really neat application-related use for it) > >Peter Furniss > >-------------------------------------- >Associate >Open-IT Limited >58 Alexandra Crescent, Bromley, Kent BR1 4EX, UK >Phone & fax : +44 (0) 20 7729 9012) >Email : P.Furniss@mailbox.ulcc.ac.uk > > > >Ram Jeyaraman sent : > >> also are we planning to include this change for issue 3343 ? >> >> A minor correction to issue 3343 which adds the following text to the Synchronization interface >> definition. Since the after_completion method need not be called with a transaction context, >> ALLOWS_SHARED would be an ideal choice instead of REQUIRES_SHARED. >> >> ----------------------------- PROPOSED TEXT --------- >> // TransactionalObject has been deprecated. See 10.3.10. >> // Use a TransactionPolicyValue of "ALLOWS_SHARED" to >> // indicate transactionality. >> interface Synchronization : TransactionalObject { >> void before_completion(); >> void after_completion(in Status status); >> }; >> -----------------------------> END >> >> thanks >> Ram >> >> >> >> Blake Biesecker wrote: >> > >> > On Tue, Jun 06, 2000 at 12:44:25PM -0400, Jishnu Mukerji wrote: >> > [snip] >> > > >> > > One minor comment on the resolution for Issue 1850.... Just for >> > > completeness's sake shouldn't we state that the unsigned long value >> > > returned by the get_timeout operation represents the timeout period in >> > > number of seconds (at least that is what I gather it is from the >> > > resolution of issue 1851)? >> > > >> > > Regards, >> > > >> > > Jishnu. >> > >> > This is to officially announce that I am planning on making the >> > clarification Jishnu describes above as an editorial change. If >> > anyone disagrees with this change, please speak up. If there is >> > even one objection, I will open a new issue and we can vote on the >> > change. The deadline for objecting will be Thursday, June 15th at >> > 6:00 PM. Objections received after that will be dealt with by >> > opening a new issue to reverse the editorial change. >> > >> > Please let me know if you have any questions or concerns regarding >> > this change. >> > >> > Blake >> > > > ************************************************************** Ed Cobb, Vice President, Advanced Technology & Standards BEA Systems, Inc., 2315 North First St., San Jose, CA 95131 Tel: 408-570-8264 / Fax: 408-570-8942 E-mail: ed.cobb@beasys.com ************************************************************** From: Peter Furniss To: Peter Furniss , "'Edward Cobb'" Cc: "ots-rtf@omg.org" Subject: RE: issue 3343 (in vote 2) (was RE: Editorial change to issue1850) Date: Fri, 9 Jun 2000 00:47:40 +0100 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by emerald.omg.org id TAA06664 Content-Type: text/plain; charset="us-ascii" X-UIDL: A4/e9aVh!!ST_d9YMW!! Edward Cobb sent : > A historical note about Synchronization. The intended use of > synchronization (and the one adopted by both EJB and CCM) is to > provide a > signal from the transaction coordinator to flush the object cache > back to > the database so the DB can manage transaction durability. That means > that > the implementation will ultimately have to execute an SQL call, > which with > an XA DB manager requires thread-specific transactions. This has > been > reworked some with JDBC and PSS since the XA standard doesn't really > support multi-threading in an unambiguous way, so this might be no > longer > necessary. But somebody will have to associate the proper > transaction with > the thread which will write back the cache. Thanks - I knew that was the general idea, though wasn't aware of the XA tie-in as such. But I still think it's bent or broken: if the immediate coordinator is in fact interposed, it will have received a Resource::prepare, which won't carry a context, so it will have to reconstruct it (unless the interposed coordinator registers itself as both Resource and Synchronization) the before_completion MUST have a context available, and the after_completion MUST NOT be passed one - however things get juggled, we don't yet have policies to say half an interface has REQUIRES_SHARED and half of it has REQUIRES_NONE whatever it was registered the synchronization object must have known the transaction identity (it at least had the coordinator reference, and could fish out the full context if it likes). It can remember this (in some form) for the future DB access. (yes, I know it's probably nicer to do this stuff in the coordinator) is this use of Synchronization supposed to work with explicit propagation ? Peter > At 11:35 PM 6/8/00 +0100, you wrote: > >Ram Jeyaraman sent (the message copied at the end) > > > > > >I don't think changing "REQUIRES_SHARED" to "ALLOWS_SHARED" on > Synchronization is that minor. But it made me look again at the text, and > I strengthen my earlier question. This is really a separate issue from > 3343, but I now believe the original vote2 text for 3343 is wrong, so I > would like to change the Open-IT vote on 3343 to NO. ( I think I've got an > hour or two left if I've got the timezones right :-) > >Apologies for raising this late > > > >Why was the Synchronization interface derived from TO, and will now be > expected to have an implicit context supplied when called, whether before > or after? It is a completely different meaning to context propagation to > that used by application interfaces. None of the rest of the OTS interfaces > themselves use it to identify which transaction they are talking about - > they all (apparently - see issue 3671) have one-off object incarnations > that are "implicitly associated with a single transaction". Without > supporting text (unless it's lurking in there and I haven't noticed), it > would even seem to be possible to invoke Synchronization operations with a > context for a *different* transaction from the one they are involved with > (I can't imagine why anyone would). > > > >But in the case of after_completion, with checking, it would be illegal to > propagate the original context anyway. > > > >This all seems so odd I wonder if I've grossly misunderstood something. > Synchronization is always a bit peculiar anyway (though I've recently found > a really neat application-related use for it) > > > >Peter Furniss > > > >-------------------------------------- > >Associate > >Open-IT Limited > >58 Alexandra Crescent, Bromley, Kent BR1 4EX, UK > >Phone & fax : +44 (0) 20 7729 9012) > >Email : P.Furniss@mailbox.ulcc.ac.uk > > > > > > > >Ram Jeyaraman sent : > > > >> also are we planning to include this change for issue 3343 ? > >> > >> A minor correction to issue 3343 which adds the following text to the > Synchronization interface > >> definition. Since the after_completion method need not be called with a > transaction context, > >> ALLOWS_SHARED would be an ideal choice instead of REQUIRES_SHARED. > >> > >> ----------------------------- PROPOSED TEXT --------- > >> // TransactionalObject has been deprecated. See 10.3.10. > >> // Use a TransactionPolicyValue of "ALLOWS_SHARED" to > >> // indicate transactionality. > >> interface Synchronization : TransactionalObject { > >> void before_completion(); > >> void after_completion(in Status status); > >> }; > >> -----------------------------> END > >> > >> thanks > >> Ram > >> > >> > >> > >> Blake Biesecker wrote: > >> > > >> > On Tue, Jun 06, 2000 at 12:44:25PM -0400, Jishnu Mukerji wrote: > >> > [snip] > >> > > > >> > > One minor comment on the resolution for Issue 1850.... Just for > >> > > completeness's sake shouldn't we state that the unsigned long value > >> > > returned by the get_timeout operation represents the timeout period in > >> > > number of seconds (at least that is what I gather it is from the > >> > > resolution of issue 1851)? > >> > > > >> > > Regards, > >> > > > >> > > Jishnu. > >> > > >> > This is to officially announce that I am planning on making the > >> > clarification Jishnu describes above as an editorial change. If > >> > anyone disagrees with this change, please speak up. If there is > >> > even one objection, I will open a new issue and we can vote on the > >> > change. The deadline for objecting will be Thursday, June 15th at > >> > 6:00 PM. Objections received after that will be dealt with by > >> > opening a new issue to reverse the editorial change. > >> > > >> > Please let me know if you have any questions or concerns regarding > >> > this change. > >> > > >> > Blake > >> > > > > > > > ************************************************************** > Ed Cobb, Vice President, Advanced Technology & Standards > BEA Systems, Inc., 2315 North First St., San Jose, CA 95131 > Tel: 408-570-8264 / Fax: 408-570-8942 > E-mail: ed.cobb@beasys.com > ************************************************************** > X-Sender: ecobb@svlhome2.beasys.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Thu, 08 Jun 2000 17:12:46 -0700 To: Peter Furniss From: Edward Cobb Subject: RE: issue 3343 (in vote 2) (was RE: Editorial change to issue1850) Cc: "ots-rtf@omg.org" In-Reply-To: <01BFD1AC.52D787A0@B193.ds.ulcc.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-UIDL: mR3e9=cPd9%U@!!Fm*!! Comments below. At 12:47 AM 6/9/00 +0100, Peter Furniss wrote: >Edward Cobb sent : > >> A historical note about Synchronization. The intended use of >> synchronization (and the one adopted by both EJB and CCM) is to provide a >> signal from the transaction coordinator to flush the object cache back to >> the database so the DB can manage transaction durability. That means that >> the implementation will ultimately have to execute an SQL call, which with >> an XA DB manager requires thread-specific transactions. This has been >> reworked some with JDBC and PSS since the XA standard doesn't really >> support multi-threading in an unambiguous way, so this might be no longer >> necessary. But somebody will have to associate the proper transaction with >> the thread which will write back the cache. > >Thanks - I knew that was the general idea, though wasn't aware of the XA tie-in as such. > >But I still think it's bent or broken: > > if the immediate coordinator is in fact interposed, it will have received a Resource::prepare, which won't carry a context, so it will have to reconstruct it (unless the interposed coordinator registers itself as both Resource and Synchronization) > Registering yourself as either a Resource or a Synchronization doesn't work, since both are transaction-specific and a resource manager (which is what an intermediate coordinator is), can have many transactions associated with itself. So either you create multiple objects, one for each transaction you are involved in, or you serialize access to yourself (which can cause deadlocks). >the before_completion MUST have a context available, and the after_completion MUST NOT be passed one - however things get juggled, we don't yet have policies to say half an interface has REQUIRES_SHARED and half of it has REQUIRES_NONE > It is true that before_completion requires a context and that after_completion doesn't actually need one (the transaction may have ended if this is the root of the tree), so a policy value that always propagates the context will work for both. ALLOWS_SHARED is sufficient to do both. Note that if this is not the root Coordinator, there will be an active transaction context at after_completion time as well (unless Synchronization objects were registered when transactions were exported). >whatever it was registered the synchronization object must have known the transaction identity (it at least had the coordinator reference, and could fish out the full context if it likes). It can remember this (in some form) for the future DB access. (yes, I know it's probably nicer to do this stuff in the coordinator) > An object that registers a Resource (or a Synchronization) gets the current transaction as thread-specific state and can retrieve the Coordinator by doing a Current.get_control followed by a Control.get_coordinator. For the interposition case, the OTS interceptor has access to the Service context and can obtain the Coordinator reference from that. It could register a Synchronization as well as a Resource, but that would give you a four-phase commit, not nice for performance. Since caching is always local, I'd never expect an interposed Coordinator to register a Synchronization with its superior. >is this use of Synchronization supposed to work with explicit propagation ? > I'm not convinced that explicit propagation works in any form, with or without Synchronization and I'd be in favor of removing it. > >Peter > > >> At 11:35 PM 6/8/00 +0100, you wrote: >> >Ram Jeyaraman sent (the message copied at the end) >> > >> > >> >I don't think changing "REQUIRES_SHARED" to "ALLOWS_SHARED" on >> Synchronization is that minor. But it made me look again at the text, and >> I strengthen my earlier question. This is really a separate issue from >> 3343, but I now believe the original vote2 text for 3343 is wrong, so I >> would like to change the Open-IT vote on 3343 to NO. ( I think I've got an >> hour or two left if I've got the timezones right :-) >> >Apologies for raising this late >> > >> >Why was the Synchronization interface derived from TO, and will now be >> expected to have an implicit context supplied when called, whether before >> or after? It is a completely different meaning to context propagation to >> that used by application interfaces. None of the rest of the OTS interfaces >> themselves use it to identify which transaction they are talking about - >> they all (apparently - see issue 3671) have one-off object incarnations >> that are "implicitly associated with a single transaction". Without >> supporting text (unless it's lurking in there and I haven't noticed), it >> would even seem to be possible to invoke Synchronization operations with a >> context for a *different* transaction from the one they are involved with >> (I can't imagine why anyone would). >> > >> >But in the case of after_completion, with checking, it would be illegal to >> propagate the original context anyway. >> > >> >This all seems so odd I wonder if I've grossly misunderstood something. >> Synchronization is always a bit peculiar anyway (though I've recently found >> a really neat application-related use for it) >> > >> >Peter Furniss >> > >> >-------------------------------------- >> >Associate >> >Open-IT Limited >> >58 Alexandra Crescent, Bromley, Kent BR1 4EX, UK >> >Phone & fax : +44 (0) 20 7729 9012) >> >Email : P.Furniss@mailbox.ulcc.ac.uk >> > >> > >> > >> >Ram Jeyaraman sent : >> > >> >> also are we planning to include this change for issue 3343 ? >> >> >> >> A minor correction to issue 3343 which adds the following text to the >> Synchronization interface >> >> definition. Since the after_completion method need not be called with a >> transaction context, >> >> ALLOWS_SHARED would be an ideal choice instead of REQUIRES_SHARED. >> >> >> >> ----------------------------- PROPOSED TEXT --------- >> >> // TransactionalObject has been deprecated. See 10.3.10. >> >> // Use a TransactionPolicyValue of "ALLOWS_SHARED" to >> >> // indicate transactionality. >> >> interface Synchronization : TransactionalObject { >> >> void before_completion(); >> >> void after_completion(in Status status); >> >> }; >> >> -----------------------------> END >> >> >> >> thanks >> >> Ram >> >> >> >> >> >> >> >> Blake Biesecker wrote: >> >> > >> >> > On Tue, Jun 06, 2000 at 12:44:25PM -0400, Jishnu Mukerji wrote: >> >> > [snip] >> >> > > >> >> > > One minor comment on the resolution for Issue 1850.... Just for >> >> > > completeness's sake shouldn't we state that the unsigned long value >> >> > > returned by the get_timeout operation represents the timeout period in >> >> > > number of seconds (at least that is what I gather it is from the >> >> > > resolution of issue 1851)? >> >> > > >> >> > > Regards, >> >> > > >> >> > > Jishnu. >> >> > >> >> > This is to officially announce that I am planning on making the >> >> > clarification Jishnu describes above as an editorial change. If >> >> > anyone disagrees with this change, please speak up. If there is >> >> > even one objection, I will open a new issue and we can vote on the >> >> > change. The deadline for objecting will be Thursday, June 15th at >> >> > 6:00 PM. Objections received after that will be dealt with by >> >> > opening a new issue to reverse the editorial change. >> >> > >> >> > Please let me know if you have any questions or concerns regarding >> >> > this change. >> >> > >> >> > Blake >> >> >> > >> > >> > >> ************************************************************** >> Ed Cobb, Vice President, Advanced Technology & Standards >> BEA Systems, Inc., 2315 No