29

I have an EntityManagerFactory for which I can create one (or multiple) EntityManager instances. I'm using a Servlet environment, and I've got one EntityManagerFactory wired up to the servlet (via the servlet context) which is shared for the lifetime of the servlet (and therefore, for all users).

I can do one of the following:

  • Create a single EntityManager for the lifetime of my servlet (e.g. shared between all users)
  • Create one per user (so each user gets their own in the HttpSession)
  • Create one per HTTP request (say, by instantiating a new one and closing it at the end of a doGet method)

Which is most appropriate? Is the cost of creating an EntityManager significant? If I do a single shared EntityManager, is there a single transaction scope (i.e. updates between independent users could commit others changes)?

AlBlue
  • 20,872
  • 14
  • 63
  • 85

3 Answers3

29

One EM for the whole servlet doesn't sound good. If you're not using container-managed EM's (for example EJB3) then the recommentation is to use an EM for a particular unit of work.

In a web application context your third suggestion (one per HTTP request) sounds good. However this may lead you down a pitfall where you are tying your service layer with your db layer (your service layer shouldn't even be aware of the existance of an EM).

Another approach would be to programatically demark transactions in your DAO and get your DAO to use a new EM for for every method call.

Edit: EMs are cheap to create as opposed to EMFs which have a significant overhead. Using one EMF (which it appears that you do) and lots of EMs is the way to go.

Qwerky
  • 17,564
  • 6
  • 43
  • 76
  • Agreed. I would totally suggest you use an integration framework like EJB 3 or the Spring Framework which will take away the burden of EntityManager management. – Philipp Jardas Nov 19 '10 at 15:29
1

we do one injected entity manager for each slsb, - and the slsb is itself accessed via a delegate, of which there is one per session, which looks up the local/remote interface. Using ejb3.0.

NimChimpsky
  • 43,542
  • 55
  • 186
  • 295
  • How can there be one stateless bean per session? Stateless beans are by definition not bound to sessions. – Philipp Jardas Nov 19 '10 at 15:26
  • @Philipp Jardas edited. Stateless beans are defined as not storing conversational state/data which is serialiazable. So its perfectly valid to create one instance of an slsb for each session. It is my understanding they have much less overhead than a SFSB. – NimChimpsky Nov 19 '10 at 16:13
  • "valid to create one instance of an slsb for each session". Since when did we get a factory method that allow us to create stateless EJB instances? I think you meant stateful EJB:s which the application control the life cycle of (each lookup produce a new bean, and application has to call @Remove method or let the bean timeout) or implicitly control the life cycle of through CDI (for example using @SessionScoped). – Martin Andersson Nov 24 '15 at 17:06
0

Yes, I agree with NimChimpsky and Qwerky to use EJB3.x when accessing DBs and to use one EM per unit of work.

Puce
  • 34,375
  • 9
  • 72
  • 137