[GLASSFISH-20530] PSR:FUNC Scrumtoys sample incorrectly handles transaction Created: 14/May/13  Updated: 15/May/13  Resolved: 15/May/13

Status: Closed
Project: glassfish
Component/s: sample_apps
Affects Version/s: 4.0_b88_RC4
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Scott Oaks Assignee: Snjezana Sevo-Zenzerovic
Resolution: Duplicate Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: File ScrumToys.war    
Tags: PSRBUG

 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|#]



 Comments   
Comment by marina vatkina [ 14/May/13 ]

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

Comment by Scott Oaks [ 14/May/13 ]

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.

Comment by marina vatkina [ 14/May/13 ]

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

Comment by Scott Oaks [ 14/May/13 ]

Reassigning to samples.

Comment by Ed Burns [ 15/May/13 ]

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

Comment by Scott Oaks [ 15/May/13 ]

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

Generated at Tue Aug 04 15:09:21 UTC 2015 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.