On 12/24/11 9:45 PM, Selcuk AYA wrote:
On Sat, Dec 24, 2011 at 9:33 PM, Alex Karasulu<akaras...@apache.org> wrote:
On Sat, Dec 24, 2011 at 3:51 PM, Emmanuel Lecharny<elecha...@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
