Transactions and Search/Cursor

[Emmanuel Lecharny <el...@gmail.com>]

Hi,

I have added txns support in LdapCoreSessionConnection, but I have some 
issues with searches : the txn has to remain opened until the cursor is 
closed. That means the cursor must retain the txns and that the commit 
is done in the cursor.close() operation.

I think we can use the inner ClosureMonitor to do that, but the question 
is what should we do when we get an exception during the search ? I 
would suggest that a search is done this way :

Cursor cursor = null;
try
{
   cursor = connection.search( blah ) // The txn is started and stored 
into the ClosureMonitor

   while (cursor.next())
   {
     Entry result = cursor.get();
     // do whatever is needed with the entry
   }
}
finally
{
   cursor.close(); // Here, the cursor holds the current status for the 
search : successful or failure.
    // If successful, do a commit, otherwise, do a rollback
}

Does it makes sense ?

-- 
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com

Re: Transactions and Search/Cursor

[Emmanuel Lécharny <el...@apache.org>]

On 12/20/11 6:04 PM, Alex Karasulu wrote:
> On Tue, Dec 20, 2011 at 4:50 PM, Emmanuel Lecharny<el...@gmail.com>wrote:
>
>> Hi,
>>
>> I have added txns support in LdapCoreSessionConnection, but I have some
>> issues with searches : the txn has to remain opened until the cursor is
>> closed. That means the cursor must retain the txns and that the commit is
>> done in the cursor.close() operation.
>>
>>
> We need the connection to register a callback with the cursor. That way
> when it is closed we can have the LCSConnection actually close the txn.
>
>
>> I think we can use the inner ClosureMonitor to do that, but the question
>> is what should we do when we get an exception during the search ? I would
>> suggest that a search is done this way :
>>
>> Cursor cursor = null;
>> try
>> {
>>   cursor = connection.search( blah ) // The txn is started and stored into
>> the ClosureMonitor
>>
>>   while (cursor.next())
>>   {
>>     Entry result = cursor.get();
>>     // do whatever is needed with the entry
>>   }
>> }
>> finally
>> {
>>   cursor.close(); // Here, the cursor holds the current status for the
>> search : successful or failure.
>>    // If successful, do a commit, otherwise, do a rollback
>> }
>>
>> Does it makes sense ?
>>
>>
> How does the ClosureMonitor fit into this code above? This must be a new
> class I guess ... this is the first time I am seeing it. I should take a
> look at this code.`

Forget about this stupid proposal. I must have been sleepy when I wrote 
that...

We discussed with Pierre-Arnaud, and it's clear that the txn must *not* 
be stored into the monitor, not does it hs to be moved to shared : there 
is no reason for the API to expose something which is just for our 
internal use.


I have started to refactor the refactoring to come back with something 
sane.

-- 
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com

Re: Transactions and Search/Cursor

[Alex Karasulu <ak...@apache.org>]

On Tue, Dec 20, 2011 at 4:50 PM, Emmanuel Lecharny <el...@gmail.com>wrote:

> Hi,
>
> I have added txns support in LdapCoreSessionConnection, but I have some
> issues with searches : the txn has to remain opened until the cursor is
> closed. That means the cursor must retain the txns and that the commit is
> done in the cursor.close() operation.
>
>
We need the connection to register a callback with the cursor. That way
when it is closed we can have the LCSConnection actually close the txn.


> I think we can use the inner ClosureMonitor to do that, but the question
> is what should we do when we get an exception during the search ? I would
> suggest that a search is done this way :
>
> Cursor cursor = null;
> try
> {
>  cursor = connection.search( blah ) // The txn is started and stored into
> the ClosureMonitor
>
>  while (cursor.next())
>  {
>    Entry result = cursor.get();
>    // do whatever is needed with the entry
>  }
> }
> finally
> {
>  cursor.close(); // Here, the cursor holds the current status for the
> search : successful or failure.
>   // If successful, do a commit, otherwise, do a rollback
> }
>
> Does it makes sense ?
>
>
How does the ClosureMonitor fit into this code above? This must be a new
class I guess ... this is the first time I am seeing it. I should take a
look at this code.

-- 
Best Regards,
-- Alex