directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lecharny <elecha...@gmail.com>
Subject Re: Txns & tests heads up
Date Sat, 24 Dec 2011 21:04:56 GMT
On 12/24/11 9:45 PM, Selcuk AYA wrote:
> On Sat, Dec 24, 2011 at 9:33 PM, Alex Karasulu<akarasulu@apache.org>  wrote:
>>
>> On Sat, Dec 24, 2011 at 3:51 PM, Emmanuel Lecharny<elecharny@gmail.com>
>> wrote:
>>> Hi,
>>>
>>> I'm fixing tests in core-integ, and so far, I still have some issues in
>>> uathz (SearchAuthorizationIT) and in schema. All the other tests are now
>>> passing.
>>>
>>> I have moved the txns borders into the OperationManager, and for searches,
>>> the cursor commit or abort the txn in the close() and close(exception)
>>> methods.
>>>
>> Why is the OM better than the CoreSession? Just curious what made you choose
>> this route. Forgive me if this was discussed in an earlier email.
> Related to this point, just curious, how did you handle the tests that
> call CoreSession directly? Did you put txn boundaries for each call ?

It's a non issue, as the OpManager is now handling the txns. It's 
transparent.
>
>>> I think we should find a way to implicitely commit or abort the txns even
>>> if the user does not close() the cursors, otherwise it might be extremely
>>> painful for them. I was thinking about adding a finalaizer in the cursor to
>>> finish the txns, but it's not a perfect solution (as it depends on the GC to
>>> be executed.
>>
>> Oh please don't do this - we should be able to find a better solution I am
>> sure. There are a myriad of reasons why this is a bad idea IMHO. We can
>> discuss this once I settle down in one place .. .still traveling.
>>
>>> Damn I miss the C++ explicit destuctors :/).
>>> Something more useful would be to allow any txns to reuse an existing
>>> txns.
> I dont think there is any difference between closing a cursor
> explicitly and calling a destructor explicitly.
Except that there is no such thing like a destructor in Java :/ What is 
the closest is finalizer(), which are just the worst possible solution. 
This is sad that we can't have a way to tell the JVM to call a 
destructor or a finalizer when an instance is out of scope...
>   Just like it is
> reasonable to expect users to close streams or file handles, it is
> reasonable to expect users to close cursors I think.
Anyway, I don't think there is another way out :) It's the exact same 
thing with JNDI NamingEnumeration, btw (except that nobody knows that 
you *must* call the close() method on NamingEnumerations)



-- 
Regards,
Cordialement,
Emmanuel L├ęcharny
www.iktek.com


Mime
View raw message