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
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
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/)
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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.
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
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
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
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
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
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
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:
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 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
27 matches
Mail list logo
