Propagation of Persistence Contexts

[Federico Minarelli]

Hello everybody!
I hope you can help me to get a better understanding of how Persistence Contexts get propagated... I spent a lot of time with this problem but am still not sure of what happens behind the scenes..
Here follows a short description of what I have done..

I am using EJB 3.1 together with JPA2 (eclipseLink) and have the following Entities (simplified):

   Testsuite{
     Collection<Test> tests;
     String uniqueName;
    }
   Test{
     String name;
     String identifier; //To not be confused with ID, imagine e.g. "TEST-1024"
    }

They model the fact that a Testsuite groups several Tests which fall under a specific name (e.g.: "Standard testsuite"). Every time a Testsuite is executed on a Server, a file is produced that looks something like this:

Testsuite: Standard testsuite
Executed on: Server1
Started at: 2011-10-10 10:11:24

TEST-1024 "Test with name X": Success
TEST-1025 "Test whit another name": Failure
...

At this point, other Entities come into play:

TestsuiteRun{
   Collection<TestRun> testsPerformed;
   Testsuite testsuitePerformed;
   Server runOnServer;
   Date startTime;
}
Server{
  String uniqueName;
}
TestRun{
  String result;
  Test testPerformed;
}

The idea is that an output File as the one above describes a TestsuiteRun, which has an association to the TestSuite that got executed (its name is Unique) together with a collection of TestRuns, each corresponding to a Test. For brevity, in the pseudo-code above I've omitted to specify that most of the associations are bidirectional, i.e. a Test knows all of its TestRuns (and viceversa); a Machine knows all of the TestsuiteRuns which got executed on it; a TestRun knows the TestsuiteRun it belongs to, and so on..

Now, my application parses a file at a time with the twofold aim of:

inserting (if they have not been already stored) new Testsuites/Tests/Server into the DB

creating a TestsuiteRun object together with all the related TestRuns.

For better performances at point 1), I use a cache object, which gets initialized with pre-existing data from the DB and is responsible for adding new records when it is the case. Here is a reduced version of it:

@Stateful
@Singleton
public class Cache {

   @PersistenceContext(unitName = "TestManager2PU", type = PersistenceContextType.EXTENDED)
    private EntityManager em;

    @EJB
    private sessionbean.TestDAO testDAO;
//Other DAOs for other cached entities such as Server and Testsuite

    Map<String, Test> testIdentifierToTest=new TreeMap<String, Test>();

@PostConstruct
public void initialize(){
for (Test t : testDAO.findAll()) {
  testIdentifierToTest.put(t.getIdentifier(), em.merge(t));
}
}

public Test retrieveTestCreateIfNotPresent(String testIdentifier, String name, String testsuiteName){
 if (testIdentifierToTest.containsKey(testIdentifier){
   return testIdentifierToTest.get(testIdentifier);
}
Test t = //Properly create new test using parameters
    testDAO.persist(t);
    testIdentifierToTest.put(t.getIdentifier(), em.merge(t));
return t;
}
}

All of the DAOs use a Transaction-scoped EntityManager:

@PersistenceContext(unitName = "TestManager2PU")
    private EntityManager em;

As you can see, I use an extended PersistenceContext and every time I read or write to the DB I use em.merge() in order to keep the entities managed. I have read in the book "Pro JPA 2" that in situations like this the PC gets propagated (in my case from Cache to TestDAO): this should mean that doing testDao.persist(t) within retrieveTestCreateIfNotPresent() should be enough to make sure t remains managed (hence the em.merge() in this case could be omitted)?

The situation is more unclear when the file parser comes into play. The code which does the job is something like:

 final TestsuiteRunBuilder testsuiteRunBuilder = //jndiLookup
 String testsuiteName = getTestSuiteNameFormFile();
 testsuiteRunBuilder.setTestsuite(testsuiteName);
...
//Foreach test in file:
testsuiteRunBuilder.addTestRun(testIdentifier, testName, testResult, testsuiteName);
//End foreach
testsuiteRunBuilder.build();

Being the TestsuiteRunBuilder declared as follows:

@Stateful
public class TestsuiteRunBuilder{
   @EJB
    private Cache cache;
   @PersistenceContext(unitName = "TestManager2PU", type = PersistenceContextType.EXTENDED)
    private EntityManager em;

private TestsuiteRun;

@PostConstuct
public void init(){
     testsuiteRun =new TestsuiteRun();
}
    public void setTestsuite(String testsuiteName) {
       Testsuite testsuite = cache.retrieveTestsuiteCreateIfNotPresent(testsuiteName);
       testsuiteRun.setTestsuitePerformed(em.merge(testsuite)); //***
     }
    public void addTestRun(...){.....} 
   @Remove 
   public void build(){
   //Adjust reverse of bidirectional associations etc 
   em.merge(testsuiteRun);
}

}

Also this class uses an Extended PC and such a bean should live only in the time span which goes from the beginning of the file parsing to the insertion into the DB (build is annotated with Remove). Of course the associations of TestsuiteRun are instructed to propagate merge..
You can see that I've marked Cache as Singleton, as I'd like to let the cache remain in memory also for the next file..
The application seems to work, but I am not really sure why.. What happens for example when I parse the second file? In what relation is the PersistenceContext of the new (the 2nd) TestsuiteRunBuilder object with that of Cache (which should be still "alive")?


I am really, really confused... What shall I change in this design? Isn't there a way to make things easier?

Thanks a lot for your help!

Bye!

[James Sutherland]

I think you are probably making things more complicated than they need to be. Since JPA (EclipseLink) already maintains an object cache, you can probably do away with your Cache. That should simplify things considerably.

Just call find() with the id to find the entity, and if it is in the cache, it will not access the database. You will only need to call merge() if you have changed a detached object.

[Federico Minarelli]

James Sutherland wrote:I think you are probably making things more complicated than they need to be. Since JPA (EclipseLink) already maintains an object cache, you can probably do away with your Cache. That should simplify things considerably.

Just call find() with the id to find the entity, and if it is in the cache, it will not access the database. You will only need to call merge() if you have changed a detached object.

Hi and thanks for answering!
As far as I understood, shared cache is enabled by default in EclipseLink. To make sure to activate it, I added

<shared-cache-mode>ALL</shared-cache-mode>

to my persistence.xml. Shouldn't then the result of each query be automatically cached?
I've changed my Cache class to query directly the DB (throught DAOs'methods) instead of storing the values into Maps, but with a FINE log level I can see the SQL SELECT queries get executed every time I call a findXXXCreateIfAbsent() method.. What is wrong in this approach?

thanks again for your help! Bye

[James Sutherland]

If you call find() using the Id, this will first check the cache.

If you execute a Query, this will not check the cache by default. If the Query is by the Id, just use find() instead. You could also set the "eclipselink.cache-usage" Query hint to "CheckCacheByPrimaryKey", to make a Query access the cache.

If the Query is not by Id then you can use a query cache, set "eclipselink.query-results-cache"="true".