Hi

My cluster died again last night but this time horribly.
When we brought it back up, everytime we tried to start XA transactions, they timed out completely and then jboss hangs. It does not deal well with transaction time outs well. I can still access the data. I data pumped the data inserted after the last nbackup to another database whilst we did a restore. This makes me gues that normal transactioning is working, but XA transactioning has failed permanently.

My next course of action is to remove XATransactioning for everywhere except where I really really need it . Yes I confess I am one of those 40% Jboss users who leave on the default XATransaction settings for most things.

How do you set up the data source to use local transactions. I changed <xa-transaction> to <local-transaction>ion the firebird -ds.xml file that is loaded by the firebirdsql.rar (renamed jaybird 2.1.1 rar) file. Is this sufficient ? What really does <local-transaction> really mean on a JCA managed connection ?

I am in the process of splitting off the readings table from the rest of the database. It accounts for 80% of the size and 60% of the insert load, but loosing a few readings due to failure at this point is an option if it means the rest of the system remains stable. This means I need to XA Transactions from this Datasource.

Hibernate HAR files for JBoss are also JCA managed ( I think), We actually don't use any EJBs, only Hibernate. My understanding is that Hibernate is also configured as a JCA resource and uses the Jboss transaction manager automatically. Can I still use hibernate HARs with jaybird and Jboss if I turn off XA transactions on the data source or do I have to roll my own hibernate.cfg.xml file and load it manually so I can set a local transaction manager? My guess this is where I was getting lockups earlier when applying local transactions as the local connection was expecting the transaction to be committed on it but it was committed on the Jboss transaction manager instead. Eventually you start to get dead locks beecause nothing is commited as far as Firebird is concerned.

Andrew

----- Original Message -----
From: David Jencks <david_jencks@...>
To: Firebird-Java@yahoogroups.com
Sent: Thursday, March 15, 2007 3:12:47 AM GMT+0200 Africa/Harare
Subject: Re: [Firebird-Java] reuse of connection after failure.







On Mar 14, 2007 , at 7:51 PM, Roman Rokytskyy wrote:

> > I'm having a lot of trouble remembering why we won't let anyone
> close
> > a connection with an active transaction. At the moment it seems to
> > me that if the tx has not been prepared we should roll it back and
> > close the connection, otherwise just close it and the tx will be in
> > limbo.
> >
> > Can anyone remember why we made the decision we did? I think it made
> > sense at the time :-)
>
> Look at the stack trace:
>
> Caused by: org.firebirdsql.gds.GDSException: cannot disconnect
> database
> with open transactions (1 active)
> at
> org.firebirdsql.gds.impl.wire.AbstractJavaGDSImpl.readStatusVector
> (AbstractJavaGDSImpl.java:2124)
> at
> org.firebirdsql.gds.impl.wire.AbstractJavaGDSImpl.receiveResponse
> (AbstractJavaGDSImpl.java:2074)
> at
> org.firebirdsql.gds.impl.wire.AbstractJavaGDSImpl.iscDetachDatabase
> (AbstractJavaGDSImpl.java:621)
>
> We had such code before, but I have eliminated it long time ago. So
> now,
> it looks like it is Firebird who complains.
>
> The question is - should we close socket anyway?
I think so. I don't think anyone who would respond appropriately to
this message would ever get in the situation of closing a connection
with an active transaction. Firebird can't access an unprepared
transaction over more than one connection anyway, so if you use xa
you have to have a connection manager that associates the connections
with the transactions they are in. Closing a connection with an
active transaction has to mean that something has gone horribly wrong
and you have no way to recover, so rolling back any unprepared work
is acceptable. If at some point in the future the wire protocol is
improved so we can have tightly coupled branches and don't need
transaction <> connection association in the connection manager, then
we can stop rolling back unprepared work when a connection is closed.

It might be reasonable to log a message but I no longer think its
reasonable to fail to execute the users' request to close the
connection.

What do you think?

thanks
david jencks

>
> Roman
>
>