Txns & tests heads up

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

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.

The pbs I'm facing are with txns inside another txns (nothing new here, 
I was not trying to fix that, but to clean up the room before starting 
to impelment a fix).

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. Damn I miss the C++ explicit 
destuctors :/).
Something more useful would be to allow any txns to reuse an existing 
txns. Of course, there are some drawbacks, but I think it's probably a 
better approach.

Any thoughts ?

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

Re: Txns & tests heads up

[Stefan Seelmann <se...@apache.org>]

On Sat, Dec 24, 2011 at 2:51 PM, Emmanuel Lecharny <el...@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.
>
> The pbs I'm facing are with txns inside another txns (nothing new here, I
> was not trying to fix that, but to clean up the room before starting to
> impelment a fix).
>
> 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. Damn I miss the C++ explicit destuctors :/).
> Something more useful would be to allow any txns to reuse an existing txns.
> Of course, there are some drawbacks, but I think it's probably a better
> approach.

Don't use finalizer. Better let the cursors implement
java.io.Closeable, when used with the new Java7 try-with-resource
statement [1] Java takes care to close the cursors.

Kind Regards,
Stefan

[1] http://docs.oracle.com/javase/tutorial/essential/exceptions/tryResourceClose.html

Re: Txns & tests heads up

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

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

Re: Txns & tests heads up

[Selcuk AYA <ay...@gmail.com>]

On Sat, Dec 24, 2011 at 9:33 PM, Alex Karasulu <ak...@apache.org> wrote:
>
>
> On Sat, Dec 24, 2011 at 3:51 PM, Emmanuel Lecharny <el...@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 ?

>
>>
>> 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. 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.

>
>
> YES this is what we need to do for re-entry but there may need to be some
> configurable parameter for this.
>
> Maybe we can Skype on this to be fast and report back to the ML.
>
>>
>> Of course, there are some drawbacks, but I think it's probably a better
>> approach.
>>
>
> +1
>
>
> --
> Best Regards,
> -- Alex
>

Re: Txns & tests heads up

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

On 12/24/11 8:33 PM, Alex Karasulu wrote:
> On Sat, Dec 24, 2011 at 3:51 PM, Emmanuel Lecharny<el...@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.

Because there is no Bind() method in the core session, but mainly 
because the ServerContext SPI is calling the OpManager instead of the 
CoreSession.
>
>
>> 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.

It was just a random thought. Finalizer is not a good idea, as there is 
no way you can control when it's called.
>
>
>> Damn I miss the C++ explicit destuctors :/).
>> Something more useful would be to allow any txns to reuse an existing
>> txns.
>
> YES this is what we need to do for re-entry but there may need to be some
> configurable parameter for this.
>
> Maybe we can Skype on this to be fast and report back to the ML.

I'll be around tomorrow. Right now, I'm trying to fix the remaining 
tests that are not starting a txn inside another txn.


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

Re: Txns & tests heads up

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

On Sat, Dec 24, 2011 at 3:51 PM, Emmanuel Lecharny <el...@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.


> 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.


YES this is what we need to do for re-entry but there may need to be some
configurable parameter for this.

Maybe we can Skype on this to be fast and report back to the ML.


> Of course, there are some drawbacks, but I think it's probably a better
> approach.
>
>
+1


-- 
Best Regards,
-- Alex