-
1. Re: Performance Problems with EntityManager Instances
kapitanpetko Jan 20, 2010 1:52 PM (in response to j1.jonathan.m.clarke.dsl.pipex.com)Use @PersitenceContext EntityManager?
-
2. Re: Performance Problems with EntityManager Instances
j1.jonathan.m.clarke.dsl.pipex.com Jan 20, 2010 2:33 PM (in response to j1.jonathan.m.clarke.dsl.pipex.com)Thanks for the swift response Nikolay. However, I thought that @PersistenceContext was used during conversations with a client browser session, rather than on the server side, especially as I will have multiple quartz jobs running at the same time, each requiring their own transactional session. That's why I thought I needed several entitymanager instances. I can find few examples of server side implementations that resemble my requirements. What I need is an independent transaction for each of the jobs that are running under quartz. I thought that @PersistenceContext would certainly handle the transactions during front-end conversations, but how do I tell Seam that each quartz job should be considered its own conversation?
-
3. Re: Performance Problems with EntityManager Instances
j1.jonathan.m.clarke.dsl.pipex.com Jan 20, 2010 2:35 PM (in response to j1.jonathan.m.clarke.dsl.pipex.com)Looking in the Seam documentation, it says
A resource-local entity manager or an entity manager created with EntityManagerFactory.createEntityManager() (application-managed) has a one-to-one relationship with a persistence context. In other situations persistence context propagation occurs,
which is exactly what I'm doing right now, but I'd like to reduce the performance overhead of having to create these entitymanagers all the time. -
4. Re: Performance Problems with EntityManager Instances
kapitanpetko Jan 20, 2010 4:10 PM (in response to j1.jonathan.m.clarke.dsl.pipex.com)Background jobs don't have access to the session or conversation. @PersistenceContext is transaction-bound, so you get a fresh instance with every transaction. If your Quartz jobs are EJB's, they will run in a transaction by default, each with its separate @PersitenceContext. If however on SLSB calls another, the two calls will be part of the same transactions. If you need them to be independent, use @TransactionalAttribute(REQUIRES_NEW).
All of this, of course, assumes you are using EJB's.
HTH
-
5. Re: Performance Problems with EntityManager Instances
j1.jonathan.m.clarke.dsl.pipex.com Jan 20, 2010 4:52 PM (in response to j1.jonathan.m.clarke.dsl.pipex.com)Almost all of my source from the invocation of the quartz job is based on POJOs, with no Seam @ augmentation (the client-facing aspects of the application do indeed use many of the Seam facilities, though). So, an example object (let's say of type 'A') may call the following initialise() code from its constructor:
public class A {
protected EntityManager fEntityManager;
protected void initialise() {
super.initialise();
EntityManagerFactory fEntityManagerFactory = Persistence.
createEntityManagerFactory("MyApp");
fEntityManager = fEntityManagerFactory.createEntityManager();
}
public doResults() {
// Database persists.
fEntityManager.flush();
}
}
The only Seam @ augmentation I use is from an object (Let's say of type 'Manager') that calls doResults() on each of the objects that need database work performed:
@Name("manager")
class Manager {
@Transactional
public void doDatabase(A aA) {
aA.doResults();
}
}
-
6. Re: Performance Problems with EntityManager Instances
kapitanpetko Jan 21, 2010 2:14 AM (in response to j1.jonathan.m.clarke.dsl.pipex.com)If you can use EJB's, do. That would save you a lot of trouble, IMHO. If not use Seam's persistence context. (@In EntityManger) The real performance problem is the createEntityManagerFactory call, creating an EntityManager is not that expensive.