Well to associate the changes you have made in the content listener with a particular call to abort (rollback) you could use the thread id as an indicator. A local slide server tx is associated with a specific thread so you can associate any changes you make with the thread id (tid). Then rollback any changes you have made on that thread when you receive a tx abort event that's running in the same thread. Of course if you are using external transactions that are initiated from the client side with start/commit/abortTransaction in the WebdavResource then the abort/commit requests could come in on a different thread but then you can get the external transaction id (etxid) from the AbstractWebdavMethod class and use that to identify which transaction is being rolled back.
You should really think about having your content listener behave transactionally itself. Ie. when the tx start event comes in store the tid (or etxid) in a local hashmap so that you know this thread has a transaction running on it. When your content listener is called check the tid/etxid) with the hashmap and make note that you have made changes that will need to be rolled back if an abort event is sent on this tid/etxid. If you receive a commit event then all is good so you can remove the entry for this tid/etxid from the hashmap. If an abort event comes in then look in the hashmap to see if you made changes during this tx and if you did then roll them back. When you make the changes in your content listener you will need to know what you had changed in order to roll it back so you'd need to keep that information somewhere so it could be used during the abort. Of course if your content listener makes its updates to a transactional data store then you can just call the start/abort/commit methods of that data store each time that you get a start/abort/commit event yourself. Its start tx routine would return an id that you can use when you have to call its abort or commit routines. You would store and then pass it this id on an abort and the backend store will take care of cleaning up any changes it has made. For example if your content listener interacts with OfBiz or Hibernate as its data store, or directly to DB2, or Oracle, or any other DB, then you can hook into their transaction support. Warwick > -----Original Message----- > From: Jim Endicott [mailto:[EMAIL PROTECTED] > Sent: Tuesday, July 26, 2005 1:19 PM > To: Slide Developers Mailing List > Subject: RE: Content Event Listener > > > I guess I don't see the connection. I do something in the > store method of the Content Listener and later there is > something wrong, the transaction the call to store is a part > of is rolled back and the transaction listener rollback > method is called. How do I know what is being rolled back? I > don't see where I have access to the transaction from the > Content Listener or the transaction listener. > > Jim > > -----Original Message----- > From: Warwick Burrows [mailto:[EMAIL PROTECTED] > Sent: Tuesday, July 26, 2005 12:32 PM > To: Slide Developers Mailing List > Subject: RE: Content Event Listener > > > Transaction events like start, commit and abort generate > events too and you can listen for those events. They are > non-vetoable events so if you have a listener defined you can > process those events from an > eventFired() method implementation. I'm not an expert on > events/listeners but I do have a GlobalListener defined and, > though I don't process them, I have it printing out the > events that trigger the eventFired interface of my listener > to be called and the tx events are probably the only events I > have seen that trigger it. > > Of course if all you are doing is making additional updates > to Slide using the standard helpers then you won't need to > roll these back yourself as they will still be part of the > greater slide transaction that was started by > AbstractWebdavMethod.run(). But if you are making other calls > to sync up another data store then you will need to rollback > these changes. > > Warwick > > > > -----Original Message----- > > From: Jim Endicott [mailto:[EMAIL PROTECTED] > > Sent: Tuesday, July 26, 2005 11:07 AM > > To: slide-dev@jakarta.apache.org > > Subject: Content Event Listener > > > > > > I have implemented a ContentEvent Listener, everything is > > working nicely but I was wondering about notification if a > > transaction gets rolled back. > > > > While developing my Listener I noticed that throwing an > > exception will cause the transaction to be rolled back (a > > good thing), and I got to wondering if it was possible for > > something to happen after my Listener is called that could > > cause a rollback to happen? If it is possible how would I > > know that it had happened? > > > > Jim Endicott > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
