0

Reading these notes. On the EBean site page. There is a paragraph that contains:

"The natural way to manage the EntityManager with a EJB3 container is to use a Stateful Session Bean."

Also there was an exposed problem like

"How to manage EntityManager during "User Think time"?

Thus, the question: What does the EJB stateless bean do/provide that could resolve the mentioned issue with "user-think-time" ?

I guess ejb provides: "Session Management", but what is the problem to store the session on ThredLocal variable and provide it to the user on demand? And not to use EJB. Does ejb have some one-stop solution for this?

I mean, the article says that: it is bad to use the concept of Session (in hibernate) or EntityManager - because of this issue. So, it says: not need to use this at all except if you use EJB stateless bean or if you are able to provide the session management mechanism by yourself (which supposed to be hard to implement?)

ses
  • 13,174
  • 31
  • 123
  • 226

1 Answers1

0

First, keep in mind that the entire article is focused on the problem of managing an EntityManager when running outside of a container. The reason is that container-managed JPA injects transaction-aware EntityManager proxies when you use @PersistenceContext.

I don't know what "user think time" is, so I don't know what problem needs to be solved. As you note, you could use a ThreadLocal to manage your EntityManager if you cannot use container-managed JPA for some reason. Of course, you must be careful to properly clear and scope the contents of the ThreadLocal.

Ultimately, there is very little that EJB provides that you couldn't do yourself if you invested enough effort. Choosing to use EJB is the same as choosing to use any other library/architecture: someone else maintains it, improves it, etc., but you have to adapt to the infrastructure. EJB perhaps has a slight advantage because it's backed by a standard that many companies implement.

Brett Kail
  • 33,593
  • 2
  • 85
  • 90
  • about user think time: http://docs.jboss.org/hibernate/orm/3.5/reference/en-US/html/transactions.html "In order to reduce lock contention in the database, a database transaction has to be as short as possible. Long database transactions will prevent your application from scaling to a highly concurrent load. It is not recommended that you hold a database transaction open during user think time until the unit of work is complete." – ses Jan 11 '13 at 17:13