I am saying this because clearly TxnManager does not belong in shared if we just step back and think about it. Yes the mechanics of the code is making us consider this but we should resist and see what we can do with some pattern to decouple this.
On Tue, Dec 20, 2011 at 7:00 PM, Alex Karasulu <akaras...@apache.org> wrote: > > On Tue, Dec 20, 2011 at 5:41 PM, Emmanuel Lecharny <elecha...@gmail.com>wrote: > >> Hi, >> >> if we want to make the search operation part of the transaction, then we >> may need to move the Txnmanager to the shared-ldap library, as we don't see >> this class from any cursor. >> >> > I see what you mean. But there are ways in which we can decouple things > without having to have TxnManager moved. This can be done by registering > for Cursor close notification and there the transaction manager can be > called within an Observer type object. > > First of all I was wondering if we can use the Java Transaction API here > at all to prevent re-inventing these interfaces. Have not looked at the > overlap. > > >> The need is to be able to commit or rollback the txn when the >> cursor.close() is done (or if we've got an exception). >> >> > Again I think we can decouple this with notifications/callbacks. > > -- > Best Regards, > -- Alex > > -- Best Regards, -- Alex
