5:37 p.m.
HeuristicMixedException detection/improvement + special case for PostgreSQL driver
----------------------------------------------------------------------------------
Key: HHH-4801
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-4801
Project: Hibernate Core
Issue Type: Improvement
Affects Versions: 3.3.1
Environment: hibernate-core: 3.3.1.GA
hibernate-annotations: 3.4.0.GA
Reporter: Maillefer Jean-David
Priority: Minor
Attachments: logs.txt
It would be nice to check, on new transaction's participant arrival, if it's
XA-disabled and it's not the first XA-disabled participant. In which case, throw an
Exception related to transaction atomicity non guaranteed (except if some config option in
[com.arjuna.ats.arjuna.coordinator] allow it).
"XA-disabled" may means more than expected. For example, when the
postgresql's parameter max_prepared_transactions is 0 (which is the default from
version 8.4), the prepared transactions are disabled and all clients (including hibernate)
will be unable to do prepared transactions (thus to participate in XA transactions). And
this happens even when using the org.postgresql.xa.PGXADataSource as XA datasource class,
since it's a server .
But in this case, it is very easy for the XA transaction coordinator to detect that
postgresql can't participate in XA transactions (issuing a "show
max_prepared_transactions" command, checking this value not 0, and displaying an
explicit error message if it's not the case).
This feature (more accurate and earlier error report) could avoid (without being
pessimistic) Hibernate transaction manager starting XA transaction that may be impossible
to do atomically.
Sample scenario:
@Entity
public class MyEntity {
@Id
int id;
public int getId() {
return id;
}
public void setId(int id) {
this.id = id;
}
}
@Stateless
public class MyStatelessBean {
@PersistenceContext
private EntityManager entityManager;
@Timeout
public void timeout(javax.ejb.Timer timer) {
// nothing needed
}
public void launchTest() {
// transaction involving first XA participant: the postgresql database (XA, but
prepared transaction may be disabled on server. This means behaves like not-XA)
MyEntity myEntity = new MyEntity();
myEntity.setId(34);
entityManager.persist(myEntity);
// involve the second XA participant: the JBoss timer datastore (not XA [else
everything would work since the coordinator allows at maximum one not-XA])
TimerService timerService = context.getTimerService();
timerService.createTimer(2500, );
}
}
Calling MyStatelessBean.runTest() in a transaction will cause many warnings from the
arjuna coordinator, followed by a javax.transaction.HeuristicMixedException (see
attachement for full logs + stacktrace).
There is an additional problem: this unended transaction is kept in the server waiting to
be fixed and the coordinator logs a warning message very often about it. These
transactions are impossible to abort and they must be removed from the JBoss datastore
manually. If many such XA transaction happen, they add all their unended XA
transaction's state in the datastore, filling this datastore and the logs.
The warning looks like this:
16:00:23,681 WARN [loggerI18N]
[com.arjuna.ats.internal.jta.resources.arjunacore.norecoveryxa]
[com.arjuna.ats.internal.jta.resources.arjunacore.norecoveryxa] Could not find new
XAResource to use for recovering non-serializable XAResource < 131075, 28, 26,
49454551102535510210110054585797485852985210099569748585157564551102535510210110054585797485852985210099569748585157100
>
Wouldn't it be better to not start such XA transactions at all since we cannot
atomically rollback after the second non-XA participant has started it's transaction
(and changes are done by the participants).
Note: this feature request follows my comment in the wiki
http://community.jboss.org/wiki/TxNonSerializableXAResource.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://opensource.atlassian.com/projects/hibernate/secure/Administrators....
-
For more information on JIRA, see: http://www.atlassian.com/software/jira