Hi Alex,I just discussed this with Emmanuel, and like you, I think the transaction does not belong in shared.It's really meant to be placed between the piece of code which captures LDAP requests on the server and the various partition back-end implementations.
I haven't looked at the code closely, but I think a simple class extending our cursor implementation in shared, with the close() method overridden, should probably do the trick.This would leave most of the cursor behavior implementation in shared where we need "basic" cursor, while letting us do additional stuff on the server side by overriding methods and calling super.methodName() to inherit the default behavior.
Regards,Pierre-ArnaudOn 20 déc. 2011, at 18:01, Alex Karasulu wrote: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 <firstname.lastname@example.org> wrote:--On Tue, Dec 20, 2011 at 5:41 PM, Emmanuel Lecharny <email@example.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