Issue 2501: Premature in eliminating Txn interfaces? (notif_service-rtf) Source: (, ) Nature: Uncategorized Issue Severity: Summary: Summary: I feel there is a flaw in the model described in the current Notification Service spec for supporting Transactional Notification. Resolution: Revised Text: Actions taken: March 3, 1999: received issue Discussion: End of Annotations:===== From: "Michael J. Greenberg" Subject: Maybe we were premature in eliminating Txn interfaces... To: notif_service-rtf@omg.org, issues@omg.org Date: Tue, 2 Mar 1999 23:35:17 -0500 (EST) Hello, I feel there is a flaw in the model described in the current Notification Service spec for supporting Transactional Notification. In the first version of the spec that was formally adopted last June, we explicitly defined Txn* versions of all interfaces that support event transmission operations. These include Txn*PushConsumer, Txn*PullSupplier, Txn*ProxyPushConsumer, and Txn*ProxyPullSupplier where * can be nothing, Structured, or Sequence. These interfaces were defined to multiply inherit from their non-Txn equivalent, and CosTransactions::TransactionalObject. The idea behind this was that in order to support the implementation of transactional varients of objects supporting these interfaces (i.e., so that event transmission can occur within the context of a transaction), it is necessary to pass the transaction context within invocations of the event transmission operations supported by these interfaces. In the original model defined by CosTransactions, this required inheritence from the TransactionalObject interface. But, within the revision of Notification that was formally adopted as the result of the first RTF, we removed the explicit definition of the Txn interfaces. We did this because a new revision of the CosTransaction service has removed the requirement that objects must inherit the TransactionalObject interface in order to guarantee that they will be passed the transaction context when their methods are invoked. But, as I study the CosTransaction service more closely, I now feel that it would have been appropriate in our original model if the Txn* interfaces we defined had also inherited the CosTransactions::Resource interface. It is the Resource interface that enables objects to participate in a transaction commit or rollback operation. Since the main idea behind transactional Notification was that events should not actually be delivered to the target entity unless the transaction within which they are transmitted commits, the objects supporting the Txn* interfaces required the ability to behave differently depending on whether the transaction commits or aborts (and in the case of abort, the need to be able to rollback their state to that which existed prior to receipt of the event). In order to do that, they should have been defined to inherit the Resource interface in addition to the TransactionalObject interface. So, while I think we did the right thing by eliminating inheritence from the TransactionalObject interface, I think we need to reintroduce these Txn* interfaces within the next revision, and have them multiply inherit from their non-Txn* counterpart, and CosTransactions::Resource. For example, CosNotifyChannelAdmin::TxnProxyPushConsumer would be defined to multiply inherit CosNotifyChannelAdmin::ProxyPushConsumer, and CosTransactions::Resource. This is necessary to ensure that a TxnProxyPushConsumer can participate in a rollback in the case a transaction within whose context it receives an event aborts, so that it can restore its state which existed prior to receiving the event. I am particularly interested in comments to this proposal from anyone who has strong knowledge of both Notification and Transactions. Regards, Mike -- Michael J. Greenberg NEC Systems, Inc. 4 Independence Way Tel. 609-734-6142 Princeton, NJ 08540 Fax. 609-734-6001 mjg@syl.nj.nec.com Sender: jon@floorboard.com Date: Tue, 02 Mar 1999 21:01:15 -0800 From: Jonathan Biggar X-Accept-Language: en To: "Michael J. Greenberg" CC: notif_service-rtf@omg.org, issues@omg.org Subject: Re: Maybe we were premature in eliminating Txn interfaces... References: <199903030435.XAA22566@syl.syl.nj.nec.com> "Michael J. Greenberg" wrote: > But, as I study the CosTransaction service more closely, I now feel > that > it would have been appropriate in our original model if the Txn* > interfaces > we defined had also inherited the CosTransactions::Resource > interface. It > is the Resource interface that enables objects to participate in a > transaction commit or rollback operation. Since the main idea behind > transactional Notification was that events should not actually be > delivered > to the target entity unless the transaction within which they are > transmitted > commits, the objects supporting the Txn* interfaces required the > ability > to behave differently depending on whether the transaction commits > or aborts > (and in the case of abort, the need to be able to rollback their > state to > that which existed prior to receipt of the event). In order to do > that, > they should have been defined to inherit the Resource interface in > addition > to the TransactionalObject interface. > > So, while I think we did the right thing by eliminating inheritence > from > the TransactionalObject interface, I think we need to reintroduce > these Txn* > interfaces within the next revision, and have them multiply inherit > from > their non-Txn* counterpart, and CosTransactions::Resource. For > example, > CosNotifyChannelAdmin::TxnProxyPushConsumer would be defined to > multiply > inherit CosNotifyChannelAdmin::ProxyPushConsumer, and > CosTransactions::Resource. This is necessary to ensure that a > TxnProxyPushConsumer can participate in a rollback in the case a > transaction > within whose context it receives an event aborts, so that it can > restore its > state which existed prior to receiving the event. > > I am particularly interested in comments to this proposal from > anyone > who has strong knowledge of both Notification and Transactions. Actually, Michael, this isn't necessary. The client program that uses the notification interfaces doesn't need direct access to anything that is defined in CosTransactions::Resource. So an implementor may very well define his own interface that inherits from both a notification interface and CosTransactions::Resource, there is merely an implementation detail, and does not need to be specified in the Notification standard. Besides, this would constrain the implementation more than necessary, since there may be other ways of achieving integration of CosNotification with CosTransaction that does not require that each notification interface inherit from Resource. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org