glassfish
  1. glassfish
  2. GLASSFISH-18166

domain.xml resource-ref / jdbc-resource mismatch prevents JPA/JTA transaction rollback

    Details

    • Type: Bug Bug
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: 3.1.1_b12, 3.1.1
    • Fix Version/s: None
    • Component/s: None
    • Labels:
      None

      Description

      I had an issue where JDBC connections were in autoCommit mode even though a JTA transaction was in progress, effectively breaking the transaction's ability to roll back.

      The trigger for this condition was editing domain.xml - I had edited the JNDI name for my connection pool (<jdbc-resource>) in domain.xml without changing the corresponding <server>/<resource-ref> element. Unfortunately, JPA was still able to find my connection pool, but the returned connections were in autoCommit mode and didn't participate in the transaction.

      Steps to reproduce:

      1. Set up a JNDI datasource jdbc/TEST through the admin UI and run the below test() method via attached JSF page or other CDI mechanism - will print "ok, autoCommit = false"

      2. Edit domain.xml, change <resource-ref ref="jdbc/TEST"> to jdbc/TEST2 or something like that.

      3. Restart Glassfish and try again - will print "problem – autoCommit = true, should be false!"

      Sample code attached.

      <?xml version="1.0" encoding="UTF-8"?>
      <persistence version="2.0" xmlns="http://java.sun.com/xml/ns/persistence"
          xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
          xsi:schemaLocation="http://java.sun.com/xml/ns/persistence http://java.sun.com/xml/ns/persistence/persistence_2_0.xsd">
      	<persistence-unit name="transactionTest">
      		<jta-data-source>jdbc/TEST</jta-data-source>
      	</persistence-unit>
      </persistence>
      
      
      package txtest;
      import java.sql.Connection;
      import javax.annotation.Resource;
      import javax.inject.Named;
      import javax.persistence.EntityManager;
      import javax.persistence.PersistenceContext;
      import javax.transaction.UserTransaction;
      
      @Named
      public class TestBean {
      	@PersistenceContext
      	private EntityManager em;	
      
      	@Resource
      	private UserTransaction utx;	
      
      	public void test() throws Exception {
      		utx.begin();
      		Connection conn = em.unwrap(Connection.class);
      		if (conn.getAutoCommit()) {
      			System.out.println("!! problem -- autoCommit = true, should be false!"); 		
      		} else {
      			System.out.println("ok, autoCommit = false");
      		}
      		utx.rollback();
      	}
      }
      
      <html xmlns="http://www.w3.org/1999/xhtml"
      	xmlns:h="http://java.sun.com/jsf/html">
      
      <h:head>
      </h:head>
      	
      <h:body>
      	<h:form>
      	<h:commandLink actionListener="#{testBean.test}">Click to test</h:commandLink>
      	</h:form>
      </h:body>
      
      </html>
      

        Activity

        wrschneider99 created issue -
        Hide
        wrschneider99 added a comment -

        BTW: I would be happy with outright failure in this mismatch case, where domain.xml is essentially corrupted. The real problem to me was that transaction semantics didn't work as expected with no indication of failure.

        If the JPA initialization had failed outright, because it couldn't find the EntityManager, that would have been fine.

        Show
        wrschneider99 added a comment - BTW: I would be happy with outright failure in this mismatch case, where domain.xml is essentially corrupted. The real problem to me was that transaction semantics didn't work as expected with no indication of failure. If the JPA initialization had failed outright, because it couldn't find the EntityManager, that would have been fine.
        Hide
        tomdcc added a comment -

        This is still happening in Glassfish 4.0. If a misconfiguration has occurred, an exception should be thrown immediately, rather than silently throwing away transactional semantics. I only discovered a misconfiguration on a test system by accident, when incomplete records started appearing.

        Show
        tomdcc added a comment - This is still happening in Glassfish 4.0. If a misconfiguration has occurred, an exception should be thrown immediately, rather than silently throwing away transactional semantics. I only discovered a misconfiguration on a test system by accident, when incomplete records started appearing.

          People

          • Assignee:
            shreedhar_ganapathy
            Reporter:
            wrschneider99
          • Votes:
            1 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated: