H2DB XA support

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

H2DB XA support

alaley
Hello!
I see that H2DB is not listed here
http://docs.codehaus.org/display/BTM/JdbcXaSupportEvaluation,
but I successfully use it in my dev/test environment. Was H2DB
inspected for XA-compliance?
I periodically check H2DB change logs and see some fixes for XA
(versions 1.2.134 from 2010-04-23 and 1.2.139 from 2010-07-10),
so it claims to be XA-compiant?

Are there any written test cases to test XA-ability for DB/drivers
that claims to be XA-compliant?
Does it have sense to periodically re-check XA-compliance for DBs?
May I help to you in this process (at least for h2db) if you need it, of cause?

Thank you,
Serge.

PS
So many questions... Excuse me for that type of mind expression.

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: H2DB XA support

Ludovic Orban-2
I've briefly evaluated H2 a few years ago and its XA support couldn't be considered usable back then, see: http://markmail.org/message/anhfau2ash3jnrf7#query:+page:1+mid:gjw5gbbkdky23df2+state:results

AFAICT the documentation hasn't changed so either it's still accurate and H2 XA still isn't usable for production use or the doc isn't accurate anymore and a re-evaluation may be worthy.

There are no automated tests for evaluating a JDBC driver's XA support, and that would be way too complex to write because of the overly-loose assumptions of the JTA spec. What I usually do is a mix of code review, testing wth BTM, testing directly the XAResource and comparing that to BTM's minimal requirements list, nice to have requirements list, generic workarounds for classic bugs list and other transaction managers known requirements. It's extremely tedious and time consuming and that's the reason why the current list is outdated.


I mentally grade implementations with one of those marks:

 - no support at all
 - not working support
 - fake support documented as such
 - incorrectly working support
 - good enough working support
 - premium working support

Databases not meeting 'good enough' or 'premium' aren't listed, and grades are secretly kept in my mind to avoid flame wars.

Last time I tested it, H2's grade was 'incorrectly working' which probably is the worst mark as usually the driver manages to pretend to be working fine until you try crash recovery and you can only kiss your data integrity goodbye.


2011/3/29 Sergey Proskurnya <[hidden email]>
Hello!
I see that H2DB is not listed here
http://docs.codehaus.org/display/BTM/JdbcXaSupportEvaluation,
but I successfully use it in my dev/test environment. Was H2DB
inspected for XA-compliance?
I periodically check H2DB change logs and see some fixes for XA
(versions 1.2.134 from 2010-04-23 and 1.2.139 from 2010-07-10),
so it claims to be XA-compiant?

Are there any written test cases to test XA-ability for DB/drivers
that claims to be XA-compliant?
Does it have sense to periodically re-check XA-compliance for DBs?
May I help to you in this process (at least for h2db) if you need it, of cause?

Thank you,
Serge.

PS
So many questions... Excuse me for that type of mind expression.

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

   http://xircles.codehaus.org/manage_email



Reply | Threaded
Open this post in threaded view
|

Re: H2DB XA support

alaley
> Last time I tested it, H2's grade was 'incorrectly working' which probably
> is the worst mark as usually the driver manages to pretend to be working
> fine until you try crash recovery and you can only kiss your data integrity
> goodbye.
>

Ok, so far we have at least one concrete point - recovery after crash.
Can you formalize it in concrete test cases?
Just describing steps, like:

1. begin XA transaction
2. perform some DML statements, modifying DB state
3. switch off host / kill DB server process
4. run up DB server again
5. tests / see what had happen...
6. make a decision based on point 5. results.

I believe that such test cases could be written to perform at least
semi-automated tests to help BTM community evaluate XA-compliance of
other exotic DBs or perform more regular XA-compliance checks (after
2-3 releases of JDBC driver for example).

Of cause the final decision is up to you - to include DB in the list or not.

Many thanks for reply,
Serge.

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: H2DB XA support

Ludovic Orban-2
Here is the flow for this particular case:

1. begin transaction
2. update data on DB1 (the one you want to test)
3. update data on DB2 (anyone, does not matter)
4. commit
5. during commit, after phase 1 is finished and before phase 2 starts, kill DB1
6. restart DB1
7. do what it takes to recover DB1
8. assert that data got updated in DB1

You need to update 2 databases to prevent 1PC to kick in.

I'll leave as an exercise up to you how to implement points 5 and 7. Just a hint: this can be hugely different between transaction managers as this is extremely implementation dependent, and the implementations vary widely, especially for point 7.




2011/3/29 Sergey Proskurnya <[hidden email]>
> Last time I tested it, H2's grade was 'incorrectly working' which probably
> is the worst mark as usually the driver manages to pretend to be working
> fine until you try crash recovery and you can only kiss your data integrity
> goodbye.
>

Ok, so far we have at least one concrete point - recovery after crash.
Can you formalize it in concrete test cases?
Just describing steps, like:

1. begin XA transaction
2. perform some DML statements, modifying DB state
3. switch off host / kill DB server process
4. run up DB server again
5. tests / see what had happen...
6. make a decision based on point 5. results.

I believe that such test cases could be written to perform at least
semi-automated tests to help BTM community evaluate XA-compliance of
other exotic DBs or perform more regular XA-compliance checks (after
2-3 releases of JDBC driver for example).

Of cause the final decision is up to you - to include DB in the list or not.

Many thanks for reply,
Serge.

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

   http://xircles.codehaus.org/manage_email



Reply | Threaded
Open this post in threaded view
|

Re: H2DB XA support

alaley
Many thanks Ludovic,

I will notify you after develop this test and getting results!

Regards,
Serge.

On Tue, Mar 29, 2011 at 2:50 PM, Ludovic Orban <[hidden email]> wrote:

> Here is the flow for this particular case:
>
> 1. begin transaction
> 2. update data on DB1 (the one you want to test)
> 3. update data on DB2 (anyone, does not matter)
> 4. commit
> 5. during commit, after phase 1 is finished and before phase 2 starts, kill
> DB1
> 6. restart DB1
> 7. do what it takes to recover DB1
> 8. assert that data got updated in DB1
>
> You need to update 2 databases to prevent 1PC to kick in.
>
> I'll leave as an exercise up to you how to implement points 5 and 7. Just a
> hint: this can be hugely different between transaction managers as this is
> extremely implementation dependent, and the implementations vary widely,
> especially for point 7.
>
>
>
>
> 2011/3/29 Sergey Proskurnya <[hidden email]>
>>
>> > Last time I tested it, H2's grade was 'incorrectly working' which
>> > probably
>> > is the worst mark as usually the driver manages to pretend to be working
>> > fine until you try crash recovery and you can only kiss your data
>> > integrity
>> > goodbye.
>> >
>>
>> Ok, so far we have at least one concrete point - recovery after crash.
>> Can you formalize it in concrete test cases?
>> Just describing steps, like:
>>
>> 1. begin XA transaction
>> 2. perform some DML statements, modifying DB state
>> 3. switch off host / kill DB server process
>> 4. run up DB server again
>> 5. tests / see what had happen...
>> 6. make a decision based on point 5. results.

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: H2DB XA support

alaley
In reply to this post by Ludovic Orban-2
I need some clarifications about the flow. Could you answer, please?
- should DB1 be started again prior 2nd phase commit (i.e. regadless
of time) or before 2nd phase commit?
- if transaction successfully prepared (1st phase commit), but can't
be performed during 2nd phase commit (no DB connection),
 wouldn't the global transaction failed and rolled back?

I want to patch btm-2.1.0 to perform this test. Do you think this
would be correct:

BitronixTransaction.commit() {
...
// prepare phase
            try {
                if (log.isDebugEnabled()) log.debug("committing, " +
resourceManager.size() + " enlisted resource(s)");

                interestedResources = preparer.prepare(this);
            }
            catch (RollbackException ex) {
                if (log.isDebugEnabled()) log.debug("caught rollback
exception during prepare, trying to rollback");

                // rollbackPrepareFailure might throw a
SystemException that will 'swallow' the RollbackException which is
                // what we want in that case as the transaction has
not been rolled back and some resources are now left in-doubt.
                rollbackPrepareFailure(ex);
                throw new BitronixRollbackException("transaction
failed to prepare: " + this, ex);
            }
 ------------> log.info("Now kill DB1 !!!");
 -----------> Thread.sleep(ENOUGH_TIME_TO_KILL_DB1);
          ...
          committer.commit(this, interestedResources);
}

of cause bitronix transaction timeout must be greater than
ENOUGH_TIME_TO_KILL_DB1.

> 1. begin transaction
> 2. update data on DB1 (the one you want to test)
> 3. update data on DB2 (anyone, does not matter)
> 4. commit
> 5. during commit, after phase 1 is finished and before phase 2 starts, kill
> DB1
> 6. restart DB1
> 7. do what it takes to recover DB1
> 8. assert that data got updated in DB1

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: H2DB XA support

Ludovic Orban-2
You are right, I typed too fast. If DB1 crashes after phase 1 but before phase 2 could start on any resource, recovery should rollback and not commit. Here's the corrected flow:

1. begin transaction
2. update data on DB1 (the one you want to test)
3. update data on DB2 (anyone, does not matter)
4. commit
5. during commit, after phase 1 is finished and before phase 2 starts, kill DB1
6. restart DB1
7. do what it takes to recover DB1
8. assert that data did NOT get updated in DB1
9. make sure the recovered transaction has been completely forgotten

and here is what it would look like if phase 2 started with DB2:

1. begin transaction
2. update data on DB1 (the one you want to test)
3. update data on DB2 (anyone, does not matter)
4. commit
5. during commit, after phase 1 is finished and after phase 2 executed on DB2, kill DB1
6. restart DB1
7. do what it takes to recover DB1
8. assert that data got updated in DB1
9. make sure the recovered transaction has been completely forgotten


It should not matter when DB1 gets restarted, the XAResource should become unusable and the transaction should be aborted. I'm not sure it's a good idea to hack a transaction manager to test this, it's probably wiser to work directly at the XAResource level.



2011/3/29 Sergey Proskurnya <[hidden email]>
I need some clarifications about the flow. Could you answer, please?
- should DB1 be started again prior 2nd phase commit (i.e. regadless
of time) or before 2nd phase commit?
- if transaction successfully prepared (1st phase commit), but can't
be performed during 2nd phase commit (no DB connection),
 wouldn't the global transaction failed and rolled back?

I want to patch btm-2.1.0 to perform this test. Do you think this
would be correct:

BitronixTransaction.commit() {
...
// prepare phase
           try {
               if (log.isDebugEnabled()) log.debug("committing, " +
resourceManager.size() + " enlisted resource(s)");

               interestedResources = preparer.prepare(this);
           }
           catch (RollbackException ex) {
               if (log.isDebugEnabled()) log.debug("caught rollback
exception during prepare, trying to rollback");

               // rollbackPrepareFailure might throw a
SystemException that will 'swallow' the RollbackException which is
               // what we want in that case as the transaction has
not been rolled back and some resources are now left in-doubt.
               rollbackPrepareFailure(ex);
               throw new BitronixRollbackException("transaction
failed to prepare: " + this, ex);
           }
 ------------> log.info("Now kill DB1 !!!");
 -----------> Thread.sleep(ENOUGH_TIME_TO_KILL_DB1);
         ...
         committer.commit(this, interestedResources);
}

of cause bitronix transaction timeout must be greater than
ENOUGH_TIME_TO_KILL_DB1.

> 1. begin transaction
> 2. update data on DB1 (the one you want to test)
> 3. update data on DB2 (anyone, does not matter)
> 4. commit
> 5. during commit, after phase 1 is finished and before phase 2 starts, kill
> DB1
> 6. restart DB1
> 7. do what it takes to recover DB1
> 8. assert that data got updated in DB1

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

   http://xircles.codehaus.org/manage_email