directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Karasulu <akaras...@apache.org>
Subject Re: TxnManager should be moved to shared-ldap
Date Tue, 20 Dec 2011 21:17:12 GMT
On Tue, Dec 20, 2011 at 7:11 PM, Pierre-Arnaud Marcelot <pa@marcelot.net>wrote:

> 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.
>
>
Glad you both feel this way.


> 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.
>
>
Sure this is yet another simpler way to do it. However it's done we can
give it a try and see how well it holds.

Best,
Alex


> Regards,
> Pierre-Arnaud
>
> On 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 <akarasulu@apache.org>wrote:
>
>>
>> On Tue, Dec 20, 2011 at 5:41 PM, Emmanuel Lecharny <elecharny@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
>
>
>


-- 
Best Regards,
-- Alex

Mime
View raw message