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 receiv
>
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
On Wed, Jun 10, 2009 at 11:34 AM, Frank Tegtmeyer 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 init
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/) impl
ng 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
>>
>>
>>
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
a
thats obviously catch a whale, hehe..
2009/6/9 nino martinez wael :
> The focus these days are to simplify frameworks, for instance take
> guice and warp persist. Really really simple to use and to setup.
> Spring has a bit to learn about java configuration from these guys (I
> last time I tried s
The focus these days are to simplify frameworks, for instance take
guice and warp persist. Really really simple to use and to setup.
Spring has a bit to learn about java configuration from these guys (I
last time I tried spring was in 2.5) however I've only tried guice
1.0.
If it takes 1 day to ut
> Ok, I think we can just agree to disagree, but will you do me a favor?
> When (not if) you encounter a situation like Martijn is talking
> about, will you post back to the list?
I just believe in principle that hunting for some bug for 3 weeks is
much less waste than dragging some toolkit along
On Tue, Jun 9, 2009 at 11:32 AM, Martin
Makundi wrote:
>> Keep convincing yourself that transaction and connection management is easy.
>
> All I can do is try to make it easy by design :)
Ok, I think we can just agree to disagree, but will you do me a favor?
When (not if) you encounter a situatio
> Having gone through 3 weeks of connection leak hunting because we
> reasoned like this and implemented our own connection and transaction
> management solution (Not Invented Here), I can say with confidence:
> this is not Premature Optimization.
Got to know your limits ;) That's a whale ...
> K
On Tue, Jun 9, 2009 at 5:12 PM, Martin
Makundi wrote:
> I say that for most cases, spring is your "premature optimization".
Having gone through 3 weeks of connection leak hunting because we
reasoned like this and implemented our own connection and transaction
management solution (Not Invented Here
No, but when I am not looking for whales, I fish just using the
fishing string and a hook with a worm tied to it.
**
Martin
2009/6/9 James Carman :
> Yeah, and do you carve a fishing pole from a tree every time you want
> to go fishing?
>
-
Yeah, and do you carve a fishing pole from a tree every time you want
to go fishing?
On Tue, Jun 9, 2009 at 11:12 AM, Martin
Makundi wrote:
> I say that for most cases, spring is your "premature optimization".
> Often it's not necessary to go further than the sea to fish. 20:80
> rule of thumb.
>
I say that for most cases, spring is your "premature optimization".
Often it's not necessary to go further than the sea to fish. 20:80
rule of thumb.
**
Martin
2009/6/9 Martijn Dashorst :
> Though Spring is a giant beast, it is a very nice one shop stop for
> your connection pooling, datasourcing
I tend to side with James. Though it seems like something you can
quickly pull out of your hat, transaction demarcation in combination
with proper connection pooling in web applications is something you'd
better get from a well tested, widely used framework rather than
suffer from NIH syndrome. Bee
On Tue, Jun 9, 2009 at 10:44 AM, Martin
Makundi wrote:
> Well, the executors themselves sure Start and Stop differently, but
> they can use same invocations for starting/stopping the entitymanagers
> (actually: in the discussed example the hooks used in Wicket are from
> EntityManagerUtils -class a
> On Tue, Jun 9, 2009 at 9:40 AM, Martin
>> In most cases I would make it thread-scoped anyways so the same
>> structure applies.
>
> Right, but you can't use the same "hooks" to start/stop your
> transactions that you do with Wicket. You have to do it at the
> executor level, while it executes th
On Tue, Jun 9, 2009 at 9:36 AM, Frank Tegtmeyer wrote:
> Can you give a (high level) overview how to handle such a situation
> in Wicket? I'm sure clients will demand such functionality someday
> from my application.
> I would use some kind of batch processing system with API calls to get
> the sta
On Tue, Jun 9, 2009 at 9:40 AM, Martin
Makundi wrote:
> In most cases I would make it thread-scoped anyways so the same
> structure applies.
>
Right, but you can't use the same "hooks" to start/stop your
transactions that you do with Wicket. You have to do it at the
executor level, while it execu
In most cases I would make it thread-scoped anyways so the same
structure applies.
**
Martin
2009/6/9 Frank Tegtmeyer :
>> 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.
>
> C
> 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.
Can you give a (high level) overview how to handle such a situation
in Wicket? I'm sure clients will demand such functionality s
> 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
wrote:
> On Tue, Jun 9, 2009 at 8:39 AM, Martin
> Makundi wrote:
> > Well.. with wicket it's easy when the transactio
On Tue, Jun 9, 2009 at 8:39 AM, Martin
Makundi 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 as
> 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:26 AM, Martin
Makundi 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)
> 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:16 AM, Martin
Makundi 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 i
> On Tue, Jun 9, 2009 at 8:00 AM, Martin
> Makundi 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, ther
Careful, that link got mangled:
https://www.hibernate.org/43.html
Hope this helps,
-Luther
On Tue, Jun 9, 2009 at 7:10 AM, Luther Baker 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 im
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
On Tue, Jun 9, 2009 at 8:00 AM, Martin
Makundi 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: user
> 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
> const
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 Tegtmeyer 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 variabl
Well when it comes to EntityManagers be sure to close, commit and
clear your threadlocal instance after your service request cycle.
**
Martin
2009/6/9 Adrian Merrall :
>>
>>
>> I try to keep my UI logic, my business logic, and my persistence
>> strategy separate. Putting the EntityManager in the
>
>
> 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 o
To stress this point: EntityManager should not be visible in Wicket
UI Eclipse Project namespace (classpath).
**
Martin
2009/6/5 Frank Tegtmeyer :
>> Putting the EntityManager in the Request means you
>> have to pass the Request around into your business logic layer.
>
> Ok, that's a convincing
> 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.
On Fri, Jun 05, 2009 at 04:28:07PM +0200, Frank Tegtmeyer wrote:
>
> > 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
> 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
-
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-entityman
> 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
>
>
>
> 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 ThreadL
> 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
--
I would just use a ThreadLocal variable in some static
EntityManagerUtil/Helper class.
**
Martin
2009/6/5 Frank Tegtmeyer :
> 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 RequestCy
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 woul
47 matches
Mail list logo
