Re: JPA EntityManager storage
Frank, Regarding your question (without joining the IOC holy-war), your experience seems odd. The wicket rad project has examples of this approach and from memory there are some slides from a wicket presentation in London on the same thing floating about so I think we can conclude it is a common approach. I actually like this approach and given that the wicket guys gave us the request cycle and such an easy way to implement our own, it seems a very wicket way to handle the problem as long as it fits your use case (all transactions inside the request). A couple of general thoughts - apologies if these are too basic. - Are you sure your Entity manager is being opened correctly and set in the threadlocal in onBeginRequest. If you are putting it in there correctly, the only way it is coming out is if you take it out. - Any chance the same entity manager is getting closed somewhere else in the code. - Are you setting your entity manager on the threadlocal during onBeginRequest by putting it on or relying on the inititalvalue for the threadlocal. This is only called once per thread on the first get. As threads are re-used, only the first requestcycle using a thread will call this. - Are you over-riding onRuntimeException as well as onEndRequest and handling the threadlocal cleanup in both places. - Leaving entity managers lying around doesn't seem ideal. I think it is better to clean them up and rely on pooling. Using dbcp with Apache openJpa gives a spectacular speedup. As above, apologies if this is all too basic, just brain dumping before bed time. Cheers, Adrian, Auckland, NZ. On Tue, Jun 9, 2009 at 11:48 PM, Frank Tegtmeyer f...@fte.to wrote: Well when it comes to EntityManagers be sure to close, commit and clear your threadlocal instance after your service request cycle. Exactly that didn't work for me. I checked for open transactions, closed them, closed the EntityManager and even released it by setting the ThreadLocal variable to null. Although I created a new EntityManager in onBeginRequest() I constantly got errors during form processing because of not existing EntityManager. I solved this by leaving EntityManager there after the request and checking for its existence at the begin of the request. Any ideas about this? Regards, Frank - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: JPA EntityManager storage
Regarding Open Session in View type patterns for JPA as Adrian mentioned, there are slides from the London Wicket event here: http://londonwicket.googlecode.com/files/LondonWicket-OpenSessionInView.pdf http://londonwicket.googlecode.com/files/LondonWicket-OpenSessionInView.pdf There is a further improved version of the Open Session in View for Wicket and JPA that provides better performance and scalability here: https://wicket-rad.svn.sourceforge.net/svnroot/wicket-rad/trunk/wicket-rad-jpa/ https://wicket-rad.svn.sourceforge.net/svnroot/wicket-rad/trunk/wicket-rad-jpa/ (not yet in any maven repo, but the code is mature, battle tested and there for the taking). It is quite easy to have a very detrimental effect on performance and scalability using the Open Session in View pattern if you are not aware of the pitfalls, which I have explained here: http://faler.wordpress.com/2009/04/30/building-a-more-scalable-open-session-in-view/ http://faler.wordpress.com/2009/04/30/building-a-more-scalable-open-session-in-view/ (the source I'm pointing to above has taken these pitfalls into consideration). / Wille Adrian Merrall wrote: Frank, Regarding your question (without joining the IOC holy-war), your experience seems odd. The wicket rad project has examples of this approach and from memory there are some slides from a wicket presentation in London on the same thing floating about so I think we can conclude it is a common approach. I actually like this approach and given that the wicket guys gave us the request cycle and such an easy way to implement our own, it seems a very wicket way to handle the problem as long as it fits your use case (all transactions inside the request). A couple of general thoughts - apologies if these are too basic. - Are you sure your Entity manager is being opened correctly and set in the threadlocal in onBeginRequest. If you are putting it in there correctly, the only way it is coming out is if you take it out. - Any chance the same entity manager is getting closed somewhere else in the code. - Are you setting your entity manager on the threadlocal during onBeginRequest by putting it on or relying on the inititalvalue for the threadlocal. This is only called once per thread on the first get. As threads are re-used, only the first requestcycle using a thread will call this. - Are you over-riding onRuntimeException as well as onEndRequest and handling the threadlocal cleanup in both places. - Leaving entity managers lying around doesn't seem ideal. I think it is better to clean them up and rely on pooling. Using dbcp with Apache openJpa gives a spectacular speedup. As above, apologies if this is all too basic, just brain dumping before bed time. Cheers, Adrian, Auckland, NZ. On Tue, Jun 9, 2009 at 11:48 PM, Frank Tegtmeyer f...@fte.to wrote: Well when it comes to EntityManagers be sure to close, commit and clear your threadlocal instance after your service request cycle. Exactly that didn't work for me. I checked for open transactions, closed them, closed the EntityManager and even released it by setting the ThreadLocal variable to null. Although I created a new EntityManager in onBeginRequest() I constantly got errors during form processing because of not existing EntityManager. I solved this by leaving EntityManager there after the request and checking for its existence at the begin of the request. Any ideas about this? Regards, Frank - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org -- View this message in context: http://www.nabble.com/JPA-EntityManager-storage-tp23888325p23962203.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: JPA EntityManager storage
Hi Adrian, - Are you setting your entity manager on the threadlocal during onBeginRequest by putting it on or relying on the inititalvalue for the threadlocal. I think you hit the problem here. The example I used (in German at http://rattlab.net/2008/10/persistenz-fur-den-feedreader/) implies that every Request uses its own thread and I never expected threads to be reused. I used simple initialization of the variable and closed the EntityManager in onEndRequest(). That highlights why I didn't like the ThreadLocal() approach - it depends on implementation details somewhere out of my control (and knowledge). Thanks to all who answered - also the discussion about Spring/Guice/whatever was informative (and entertaining). Expect to get some beginner questions from me again soon :) Regards, Frank - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: JPA EntityManager storage
On Wed, Jun 10, 2009 at 11:34 AM, Frank Tegtmeyerf...@fte.to wrote: I think you hit the problem here. The example I used (in German at http://rattlab.net/2008/10/persistenz-fur-den-feedreader/) implies that every Request uses its own thread and I never expected threads to be reused. I used simple initialization of the variable and closed the EntityManager in onEndRequest(). That highlights why I didn't like the ThreadLocal() approach - it depends on implementation details somewhere out of my control (and knowledge). The specification says that threads may be reused. So, it's not really an implementation-specific thing. Most servers implement their server threads this way, as they should. You should expect them to reuse threads. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: JPA EntityManager storage
http://faler.wordpress.com/2009/04/30/building-a-more-scalable-open-session-in-view/ Nice post. For some reason I thought Hibernate's Session could be configured to do this sort of thing intrinsically (ie: starting and ending tx are essentially noops unless something actually happened - part of the whole dirty checking thing). On another note, I know that Hibernate's Session.getCurrentSession() can be configured to be thread specific (internally using ThreadLocal) ... I've recently wondered if EntityManagerFactory.createEntityManager follows suite ? -Luther On Wed, Jun 10, 2009 at 1:04 PM, Luther Baker lutherba...@gmail.com wrote: Indeed, it can seem *spooky* to start writing code at the ThreadLocal level ... but remember, threads are created, assigned, collected and reused by the server - unless explicitly created by the application (which is highly discouraged), they are managed by the server. That said, the server receives a request, grabs a thread and assigns it to the request. I believe you can assume that same thread will start, service and end requests consistently. The OS may context switch and control may move (the thread may pause) but unless someone is trying to make their own lives extremely difficult, threads in a JEE container will not jump around randomly from request to request without completing them. (I think this might be specified in a JSR somewhere - but I can't put my finger on it right now.) -Luther On Wed, Jun 10, 2009 at 10:39 AM, James Carman jcar...@carmanconsulting.com wrote: On Wed, Jun 10, 2009 at 11:34 AM, Frank Tegtmeyerf...@fte.to wrote: I think you hit the problem here. The example I used (in German at http://rattlab.net/2008/10/persistenz-fur-den-feedreader/) implies that every Request uses its own thread and I never expected threads to be reused. I used simple initialization of the variable and closed the EntityManager in onEndRequest(). That highlights why I didn't like the ThreadLocal() approach - it depends on implementation details somewhere out of my control (and knowledge). The specification says that threads may be reused. So, it's not really an implementation-specific thing. Most servers implement their server threads this way, as they should. You should expect them to reuse threads. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: JPA EntityManager storage
Indeed, it can seem *spooky* to start writing code at the ThreadLocal level ... but remember, threads are created, assigned, collected and reused by the server - unless explicitly created by the application (which is highly discouraged), they are managed by the server. That said, the server receives a request, grabs a thread and assigns it to the request. I believe you can assume that same thread will start, service and end requests consistently. The OS may context switch and control may move (the thread may pause) but unless someone is trying to make their own lives extremely difficult, threads in a JEE container will not jump around randomly from request to request without completing them. (I think this might be specified in a JSR somewhere - but I can't put my finger on it right now.) -Luther On Wed, Jun 10, 2009 at 10:39 AM, James Carman jcar...@carmanconsulting.com wrote: On Wed, Jun 10, 2009 at 11:34 AM, Frank Tegtmeyerf...@fte.to wrote: I think you hit the problem here. The example I used (in German at http://rattlab.net/2008/10/persistenz-fur-den-feedreader/) implies that every Request uses its own thread and I never expected threads to be reused. I used simple initialization of the variable and closed the EntityManager in onEndRequest(). That highlights why I didn't like the ThreadLocal() approach - it depends on implementation details somewhere out of my control (and knowledge). The specification says that threads may be reused. So, it's not really an implementation-specific thing. Most servers implement their server threads this way, as they should. You should expect them to reuse threads. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: JPA EntityManager storage
Well when it comes to EntityManagers be sure to close, commit and clear your threadlocal instance after your service request cycle. Exactly that didn't work for me. I checked for open transactions, closed them, closed the EntityManager and even released it by setting the ThreadLocal variable to null. Although I created a new EntityManager in onBeginRequest() I constantly got errors during form processing because of not existing EntityManager. I solved this by leaving EntityManager there after the request and checking for its existence at the begin of the request. Any ideas about this? Regards, Frank - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: JPA EntityManager storage
It sounds to me like you're spending too much time fighting. You could have spent this time learning Spring (it's not that hard for what you want to do) and you'd be a happy camper right now. There's a reason so many folks use it. It works. On Tue, Jun 9, 2009 at 7:48 AM, Frank Tegtmeyerf...@fte.to wrote: Well when it comes to EntityManagers be sure to close, commit and clear your threadlocal instance after your service request cycle. Exactly that didn't work for me. I checked for open transactions, closed them, closed the EntityManager and even released it by setting the ThreadLocal variable to null. Although I created a new EntityManager in onBeginRequest() I constantly got errors during form processing because of not existing EntityManager. I solved this by leaving EntityManager there after the request and checking for its existence at the begin of the request. Any ideas about this? Regards, Frank - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: JPA EntityManager storage
Exactly that didn't work for me. I checked for open transactions, closed them, closed the EntityManager and even released it by setting the ThreadLocal variable to null. What do you mean you CHECK for open transactions? Although I created a new EntityManager in onBeginRequest() I constantly got errors during form processing because of not existing EntityManager. Use lazy loading and close it at onEndRequest(). You could have spent this time learning Spring (it's not that hard for what you want to do) and you'd be a happy camper right now. Haven't seen any benefits to Spring, yet. ** Martin - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: JPA EntityManager storage
On Tue, Jun 9, 2009 at 8:00 AM, Martin Makundimartin.maku...@koodaripalvelut.com wrote: Haven't seen any benefits to Spring, yet. Well, you're in the minority. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: JPA EntityManager storage
Maybe this link will help: https://www.hibernate.org/43.html in the class JpaUtil. I don't like this approach because it depends on the implicit assumption that each request is handled in a thread (this depends on Wicket implementation details, therefor I dislike it) This assumption is not true. It is perfectly fine to attach the EntityManager to ThreadLocal since, per the spec, each request is guaranteed to get assigned to a different thread. This is not a wicket implementation detail, it is higher than that - threads are assigned by the container. -Luther On Tue, Jun 9, 2009 at 6:48 AM, Frank Tegtmeyer f...@fte.to wrote: Well when it comes to EntityManagers be sure to close, commit and clear your threadlocal instance after your service request cycle. Exactly that didn't work for me. I checked for open transactions, closed them, closed the EntityManager and even released it by setting the ThreadLocal variable to null. Although I created a new EntityManager in onBeginRequest() I constantly got errors during form processing because of not existing EntityManager. I solved this by leaving EntityManager there after the request and checking for its existence at the begin of the request. Any ideas about this? Regards, Frank - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: JPA EntityManager storage
Careful, that link got mangled: goog_1244383468413https://www.hibernate.org/43.html Hope this helps, -Luther On Tue, Jun 9, 2009 at 7:10 AM, Luther Baker lutherba...@gmail.com wrote: Maybe this link will help: https://www.hibernate.org/43.html in the class JpaUtil. I don't like this approach because it depends on the implicit assumption that each request is handled in a thread (this depends on Wicket implementation details, therefor I dislike it) This assumption is not true. It is perfectly fine to attach the EntityManager to ThreadLocal since, per the spec, each request is guaranteed to get assigned to a different thread. This is not a wicket implementation detail, it is higher than that - threads are assigned by the container. -Luther On Tue, Jun 9, 2009 at 6:48 AM, Frank Tegtmeyer f...@fte.to wrote: Well when it comes to EntityManagers be sure to close, commit and clear your threadlocal instance after your service request cycle. Exactly that didn't work for me. I checked for open transactions, closed them, closed the EntityManager and even released it by setting the ThreadLocal variable to null. Although I created a new EntityManager in onBeginRequest() I constantly got errors during form processing because of not existing EntityManager. I solved this by leaving EntityManager there after the request and checking for its existence at the begin of the request. Any ideas about this? Regards, Frank - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: JPA EntityManager storage
On Tue, Jun 9, 2009 at 8:00 AM, Martin Makundimartin.maku...@koodaripalvelut.com wrote: Haven't seen any benefits to Spring, yet. Well, you're in the minority. That doesn't necessary mean I am wrong ;) All the fancy thins happening with spring, I just leave them out which results in a more streamlined solution. Ok, there are some integrations which are easily accomplished via Spring, but then it's just another integration library. ** Martin - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: JPA EntityManager storage
On Tue, Jun 9, 2009 at 8:16 AM, Martin Makundimartin.maku...@koodaripalvelut.com wrote: That doesn't necessary mean I am wrong ;) All the fancy thins happening with spring, I just leave them out which results in a more streamlined solution. Ok, there are some integrations which are easily accomplished via Spring, but then it's just another integration library. Yes, but the integration library is battle-tested and proven to be useful. Once you get your setup working (which can be copy and pasted from examples or autogenerated via a maven archetype like wicketopia or iolite), you don't really have to think about Spring that much anymore. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: JPA EntityManager storage
Yes, but the integration library is battle-tested and proven to be useful. Yesyes.. I would use it if I was integrating something big. However, attaching Hibernate is easier via vanilla java than via Spring configuration. ** Martin - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: JPA EntityManager storage
On Tue, Jun 9, 2009 at 8:26 AM, Martin Makundimartin.maku...@koodaripalvelut.com wrote: Yesyes.. I would use it if I was integrating something big. However, attaching Hibernate is easier via vanilla java than via Spring configuration. Good luck managing your transactions yourself (if you're not using a JTA-enabled container) - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: JPA EntityManager storage
Good luck managing your transactions yourself (if you're not using a JTA-enabled container) Well.. with wicket it's easy when the transactions are request-scoped. It's a different ballgame somewhere else.. but then we can have EJB3 or something. ** Martin - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: JPA EntityManager storage
On Tue, Jun 9, 2009 at 8:39 AM, Martin Makundimartin.maku...@koodaripalvelut.com wrote: Well.. with wicket it's easy when the transactions are request-scoped. It's a different ballgame somewhere else.. but then we can have EJB3 or something. Yes, but not all transactions are request-scoped. We have many times implemented asynchronous transactions, because the user didn't want to wait for the results. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: JPA EntityManager storage
attaching Hibernate is easier via vanilla java than via Spring configuration. attaching Hibernate is [even eaiser with Guice]! :) On Tue, Jun 9, 2009 at 7:59 AM, James Carman jcar...@carmanconsulting.comwrote: On Tue, Jun 9, 2009 at 8:39 AM, Martin Makundimartin.maku...@koodaripalvelut.com wrote: Well.. with wicket it's easy when the transactions are request-scoped. It's a different ballgame somewhere else.. but then we can have EJB3 or something. Yes, but not all transactions are request-scoped. We have many times implemented asynchronous transactions, because the user didn't want to wait for the results. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: JPA EntityManager storage
I try to keep my UI logic, my business logic, and my persistence strategy separate. Putting the EntityManager in the Request means you have to pass the Request around into your business logic layer. By putting it in a ThreadLocal, the UI and business layers can be blissfully unaware of its existance. BTW I use Spring's OpenEntityManagerInViewFilter for this. Works very well. If you are using a ThreadLocal it is worth reading this.. http://www.javaspecialists.eu/archive/Issue164.html as it covers issues of ThreadLocal and garbage collection. HTH Adrian
Re: JPA EntityManager storage
I would just use a ThreadLocal variable in some static EntityManagerUtil/Helper class. ** Martin 2009/6/5 Frank Tegtmeyer f...@fte.to: Hi, would the Request object be a good place to store a JPA EntityManager? It would be created in onBeginRequest() and destroyed in onEndRequest() of the RequestCycle object. I saw two other options already: - use a filter in combination with Spring (I don't want to use Spring yet - this would add to all the new stuff I have to learn so far) - use a ThreadLocal object like in http://rattlab.net/2008/10/persistenz-fur-den-feedreader/ in the class JpaUtil. I don't like this approach because it depends on the implicit assumption that each request is handled in a thread (this depends on Wicket implementation details, therefor I dislike it) Any advice is welcome. Regards, Frank - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: JPA EntityManager storage
I don't like this approach because it depends on the implicit assumption that each request is handled in a thread (this depends on Wicket implementation details, therefor I dislike it) Don't fall into the trap of premature optimization! ** Martin - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: JPA EntityManager storage
Don't fall into the trap of premature optimization! Hm. Maybe I'm in this trap already. But what is wrong with binding a resource directly to the request when it is used exactly for the lifetime of the request? For me this only sounds logical compared to the pragmatic approach using a ThreadLocal object. Are there any technical reasons against storing in the request? Regards, Frank - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: JPA EntityManager storage
But what is wrong with binding a resource directly to the request when it is used exactly for the lifetime of the request? a) sounds complex b) you are BINDING it. The less you have dependencies on _specific_ bound components, the better.. in general. ** Martin - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: JPA EntityManager storage
Frank Tegtmeyer wrote: would the Request object be a good place to store a JPA EntityManager? It would be created in onBeginRequest() and destroyed in onEndRequest() of the RequestCycle object. You may find these of interest: http://javanotepad.blogspot.com/2007/08/managing-jpa-entitymanager-lifecycle.html http://javanotepad.blogspot.com/2007/05/jpa-entitymanagerfactory-in-web.html Chris -- - Chris Merrill | Web Performance, Inc. ch...@webperformance.com| http://webperformance.com 919-433-1762| 919-845-7601 Website Load Testing and Stress Testing Software Services - - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: JPA EntityManager storage
You may find these of interest: http://javanotepad.blogspot.com/2007/08/managing-jpa-entitymanager-lifecycle.html Yes, if I need that level of flexibility (which I don't need). I pay with complexity of the implementation. Anyway, this is a nice lesson, thanks for the link! Regards, Frank - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: JPA EntityManager storage
To stress this point: EntityManager should not be visible in Wicket UI Eclipse Project namespace (classpath). ** Martin 2009/6/5 Frank Tegtmeyer f...@fte.to: Putting the EntityManager in the Request means you have to pass the Request around into your business logic layer. Ok, that's a convincing point. Thank you. Regards, Frank - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
