[hibernate-issues] [Hibernate-JIRA] Created: (HHH-4801) HeuristicMixedException detection/improvement + special case for PostgreSQL driver

[Maillefer Jean-David (JIRA)]

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.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira