glassfish
  1. glassfish
  2. GLASSFISH-20530

PSR:FUNC Scrumtoys sample incorrectly handles transaction

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Duplicate
    • Affects Version/s: 4.0_b88_RC4
    • Fix Version/s: None
    • Component/s: sample_apps
    • Labels:
      None

      Description

      We are using the standard scrumtoys JSF sample. Somewhere around build 83 (I haven't narrowed it down exactly – but I'd guress around the eclipse promotion in late April) this sample no longer works – when we create a project, it should be persisted, and then appear in the project list. Instead, the project list comes up empty.

      I am attaching the war file we are using. The domain is created like this:
      asadmin create-domain jsf
      asadmin start-domain jsf ../bin/asadmin create-jdbc-connection-pool --datasourceclassname org.apache.derby.jdbc.EmbeddedXADataSource JSFPool ../bin/asadmin set server.resources.jdbc-connection-pool.JSFPool.property.connectionAttributes=create=true
      asadmin set server.resources.jdbc-connection-pool.JSFPool.property.databaseName=jsf
      asadmin create-jdbc-resource --connectionpoolid JSFPool jdbc/jsf

      Click on the project tab, then click create new project, enter a name and date and click create project. The resulting screen then should have a list of the one project that was just created (which is what happens in previous builds).

      I have put debugging statements in the code where the transaction is created:

      public abstract class AbstractManager {
      @PersistenceUnit private EntityManagerFactory emf;
      @Resource UserTransaction ut;

      protected void do()

      { // Exception handling deleted EntityManager em = emf.createEntityManager(); ut.begin(); System.out.println("User transaction begins for " + em); System.out.println("Calling EM persist of " + getCurrentProject() + " on " + em); em.persist(getCurrentProject()); System.out.println("Done calling EM persist of " + getCurrentProject() + " on " + em); ut.commit(); System.out.println("User transaction committed for " + em); }

      }

      We get essentially the same output of this in build 88 (where it fails) and build 76 (where it succeeds):
      [#|2013-05-14T10:42:16.118-0700|INFO||javax.enterprise.logging.stdout|_ThreadID=17;_ThreadName=http-listener-1(1);_TimeMillis=1368553336118;_LevelValue=800;|User Transaction begins for org.eclipse.persistence.internal.jpa.EntityManagerImpl@43b8170f|#]

      [#|2013-05-14T10:42:16.118-0700|INFO||javax.enterprise.logging.stdout|_ThreadID=17;_ThreadName=http-listener-1(1);_TimeMillis=1368553336118;_LevelValue=800;|Calling EM persist of Project[name=j8,startDate=Mon May 13 17:00:00 PDT 2013,endDate=Wed Jun 12 17:00:00 PDT 2013] on em org.eclipse.persistence.internal.jpa.EntityManagerImpl@43b8170f|#]

      [#|2013-05-14T10:42:16.120-0700|INFO||javax.enterprise.logging.stdout|_ThreadID=17;_ThreadName=http-listener-1(1);_TimeMillis=1368553336120;_LevelValue=800;|Done Calling EM persist of Project[name=j8,startDate=Mon May 13 17:00:00 PDT 2013,endDate=Wed Jun 12 17:00:00 PDT 2013] on em org.eclipse.persistence.internal.jpa.EntityManagerImpl@43b8170f|#]

      [#|2013-05-14T10:42:16.171-0700|INFO||javax.enterprise.logging.stdout|_ThreadID=17;_ThreadName=http-listener-1(1);_TimeMillis=1368553336171;_LevelValue=800;|User Transaction committed for org.eclipse.persistence.internal.jpa.EntityManagerImpl@43b8170f|#]

        Activity

        Hide
        marina vatkina added a comment -

        I think you either need to get EM after you started the tx or call joinTransaction() on it.

        Show
        marina vatkina added a comment - I think you either need to get EM after you started the tx or call joinTransaction() on it.
        Hide
        Scott Oaks added a comment -

        Yes, getting EM after starting the transaction works (and of course that makes sense). I guess you saying that the sample code has been wrong for years and just happened to work until the recent eclipselink upgrade? If so – if we don't think other users will have an issue – I'll change the bug to be against the JSF sample.

        Show
        Scott Oaks added a comment - Yes, getting EM after starting the transaction works (and of course that makes sense). I guess you saying that the sample code has been wrong for years and just happened to work until the recent eclipselink upgrade? If so – if we don't think other users will have an issue – I'll change the bug to be against the JSF sample.
        Hide
        marina vatkina added a comment -

        Yes, EclipseLink became spec compliant recently. I'll let others decide what to do about users who relied on the wrong behavior.

        Show
        marina vatkina added a comment - Yes, EclipseLink became spec compliant recently. I'll let others decide what to do about users who relied on the wrong behavior.
        Hide
        Scott Oaks added a comment -

        Reassigning to samples.

        Show
        Scott Oaks added a comment - Reassigning to samples.
        Hide
        Ed Burns added a comment -

        Before proceeding I would like to ensure that Scott Oaks has the most
        current scrumtoys. Looking at the code sample he posted, I am not sure
        he does. Also, we had the same problem in glassfish-samples and fixed
        it by adding em.joinTransaction().

        First, here is the latest AbstractManager:

        public abstract class AbstractManager {
        
            @PersistenceUnit
            private EntityManagerFactory emf;
            @Resource
            private UserTransaction userTransaction;
        
            protected <T> T doInTransaction(PersistenceAction<T> action) throws ManagerException {
                EntityManager em = emf.createEntityManager();
                try {
                    userTransaction.begin();
                    em.joinTransaction();
                    T result = action.execute(em);
                    userTransaction.commit();
                    return result;
                } catch (Exception e) {
                    try {
                        userTransaction.rollback();
                    } catch (Exception ex) {
                        Logger.getLogger(AbstractManager.class.getName()).log(Level.SEVERE, null, ex);
                    }
                    throw new ManagerException(e);
                } finally {
                    em.close();
                }
        
            }
        
        //[[...]]
        }
        

        Second, here is the SVN url of the most current scrumtoys:

        https://svn.java.net/svn/glassfish-samples~svn/trunk/ws

        Within there, scrumtoys is at javaee7/jsf/scrumtoys/pom.xml.

        Once we have established that Scott is indeed running the correct
        version of the code, we can continue to debug this.

        The benefit of using this newer version is that it uses some new
        features in JSF 2.2. Also, note that there are some very important
        asadmin actions that you must take before being able to login, these are
        described in the login page of the app.

        Ed

        Show
        Ed Burns added a comment - Before proceeding I would like to ensure that Scott Oaks has the most current scrumtoys. Looking at the code sample he posted, I am not sure he does. Also, we had the same problem in glassfish-samples and fixed it by adding em.joinTransaction(). First, here is the latest AbstractManager: public abstract class AbstractManager { @PersistenceUnit private EntityManagerFactory emf; @Resource private UserTransaction userTransaction; protected <T> T doInTransaction(PersistenceAction<T> action) throws ManagerException { EntityManager em = emf.createEntityManager(); try { userTransaction.begin(); em.joinTransaction(); T result = action.execute(em); userTransaction.commit(); return result; } catch (Exception e) { try { userTransaction.rollback(); } catch (Exception ex) { Logger.getLogger(AbstractManager.class.getName()).log(Level.SEVERE, null , ex); } throw new ManagerException(e); } finally { em.close(); } } //[[...]] } Second, here is the SVN url of the most current scrumtoys: https://svn.java.net/svn/glassfish-samples~svn/trunk/ws Within there, scrumtoys is at javaee7/jsf/scrumtoys/pom.xml. Once we have established that Scott is indeed running the correct version of the code, we can continue to debug this. The benefit of using this newer version is that it uses some new features in JSF 2.2. Also, note that there are some very important asadmin actions that you must take before being able to login, these are described in the login page of the app. Ed
        Hide
        Scott Oaks added a comment -

        Original code is from netbeans sample; new scrumtoys samples are already fixed.

        Show
        Scott Oaks added a comment - Original code is from netbeans sample; new scrumtoys samples are already fixed.

          People

          • Assignee:
            Snjezana Sevo-Zenzerovic
            Reporter:
            Scott Oaks
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: