You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by Jim O'Callaghan <jc...@yahoo.co.uk> on 2010/07/21 18:33:13 UTC
non thread safe access to session
I have a service (service A) that creates some sample data, consisting of a
reasonably detailed object graph where all the relations are cascaded. This
service makes use of another service (service B) which manages the save of
the parent entity. Service B has the hibernate session injected at bind
time. I have service A called in a finite loop in the setup (@SetupRender)
method of a scratch page I use for some dev testing. To cut a long story
short, when playing around with the sample data creation, I found I was
getting some "non thread safe access to session" type messages when I
launched a second user session and hit the same scratch page. This doesn't
happen if I mark the relevant method in service A as synchronized, but this
brings with it a significant performance penalty. I'm a little concerned I
may have a situation where in a high traffic scenario multiple users hitting
the same service methods may get the same error. Can anyone reiterate the
best practise approach for marking member fields / injected parameters as
final or point me to a relevant posting on it around here - I'm sure
something about marking things as final was brought up on the list not so
long ago but for the life of me I can't find it. I'm not sure if it's
relevant but I'm using T5.2.0-SNAPSHOT. Perhaps this isn't Tapestry relevant
at all and is down to my use of Hibernate. Thanks.
Regards,
Jim.
RE: non thread safe access to session
Posted by Jim O'Callaghan <jc...@yahoo.co.uk>.
Thanks Kalle - this will be very useful for me - I'll make it more service
oriented and inject the new session.
Regards,
Jim.
-----Original Message-----
From: Kalle Korhonen [mailto:kalle.o.korhonen@gmail.com]
Sent: 22 July 2010 17:48
To: Tapestry users
Subject: Re: non thread safe access to session
To create an absolutely *new* session (even if another thread-bound
session already exists), inject HibernateSessionSource and call
hibernateSessionSource.getSessionFactory().create(), then manage
transactions and all objects in that session yourself.
Kalle
On Thu, Jul 22, 2010 at 9:38 AM, Jim O'Callaghan <jc...@yahoo.co.uk>
wrote:
> I do get direct access to the session from the under a very specific
> circumstance to allow me to commit a separate transaction unconditionally,
> to facilitate keeping a pre-allocated batch of keys in memory - I can't
have
> this transaction rolled back due to a problem somewhere else, or I am left
> with keys that the application thinks are available, but in reality the
> sequence hasn't been updated in the database due to a rollback. The new
> session is created using session.getSessionFactory().openSession() within
a
> single method invocation, which I'm guessing leaves me open to thread
safety
> issues. I'm going to rearrange it to make it more service based. I think
> this is just down to bad coding practice.
>
> Regards,
> Jim.
>
> -----Original Message-----
> From: Josh Canfield [mailto:joshcanfield@gmail.com]
> Sent: 22 July 2010 16:25
> To: Tapestry users
> Subject: Re: non thread safe access to session
>
>> I do however have some buried code where I force a transaction to commit
> to allow me to assign some non-customer facing entity keys in batches, to
> reduce db hits - this is probably causing the problem - I'll synchronize
> that as it's not called too often and hopefully that will do it. Thanks
for
> the tips guys.
>
> I'm curious why you'd need to synchronize anything to do what you've
> described. You shouldn't be getting any cross-thread access to a single
> session.
>
> -- Josh
>
> On Jul 22, 2010, at 1:16 AM, "Jim O'Callaghan" <jc...@yahoo.co.uk>
> wrote:
>
>> Jonathon, Howard,
>>
>> Thanks for the responses. I'm leaning towards Howard's explanation. The
> processes are accessing newly created / persisted objects so I don't think
> sharing attached objects across more than one session should arise. I do
> however have some buried code where I force a transaction to commit to
allow
> me to assign some non-customer facing entity keys in batches, to reduce db
> hits - this is probably causing the problem - I'll synchronize that as
it's
> not called too often and hopefully that will do it. Thanks for the tips
> guys.
>>
>> Regards,
>> Jim.
>>
>> -----Original Message-----
>> From: Jonathan Barker [mailto:jonathan.theitguy@gmail.com]
>> Sent: 22 July 2010 02:31
>> To: Tapestry users
>> Subject: Re: non thread safe access to session
>>
>> Jim,
>>
>> I have vague recollections of hitting this before.
>>
>> IIRC, each hibernate object knows the Session that it is associated with.
>> So, if an object is associated with Session A on Thread A, and you modify
>> that object from Thread B, then Session A now has to manage changes made
>> from a different thread, which presents lots of challenges.
>>
>> So, I think it's not so much about your handling of the Sessions, as it
is
>> about handling session-managed objects that get accessed from different
>> threads.
>>
>> Can you detach your objects before allowing other threads to access them?
>>
>> Regards,
>>
>> Jonathan
>>
>>
>> On Wed, Jul 21, 2010 at 1:29 PM, Jim O'Callaghan
> <jc...@yahoo.co.uk>wrote:
>>
>>> Yep Thiago, it's Tapestry-Hibernate creating the sessions. My situation
>>> might be a little contrived, but I'm concerned it might happen to
>>> end-users, as I don't fully understand why it's happening.
>>>
>>> Regards,
>>> Jim.
>>>
>>> -----Original Message-----
>>> From: Thiago H. de Paula Figueiredo [mailto:thiagohp@gmail.com]
>>> Sent: 21 July 2010 18:22
>>> To: Tapestry users
>>> Subject: Re: non thread safe access to session
>>>
>>> On Wed, 21 Jul 2010 13:58:15 -0300, Jim O'Callaghan
>>> <jc...@yahoo.co.uk> wrote:
>>>
>>>> Hi Thiago,
>>>
>>> Hi, Jim!
>>>
>>>> I'm talking about the hibernate session - I'm injecting it into the
>>>> constructor of Service B at bind time. I thought Tapestry would treat
>>>> the service as a thread safe singleton and control access to method
>>>> calls on it accordingly?
>>>
>>> Tapestry-IoC doesn't synchronize method calls. How are you building the
>>> sessions? Tapestry-Hibernate?
>>>
>>> --
>>> Thiago H. de Paula Figueiredo
>>> Independent Java, Apache Tapestry 5 and Hibernate consultant, developer,
>>> and instructor
>>> Owner, Ars Machina Tecnologia da Informa??o Ltda.
>>> http://www.arsmachina.com.br
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>>
>>>
>>
>>
>> --
>> Jonathan Barker
>> ITStrategic
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: users-help@tapestry.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: non thread safe access to session
Posted by Kalle Korhonen <ka...@gmail.com>.
To create an absolutely *new* session (even if another thread-bound
session already exists), inject HibernateSessionSource and call
hibernateSessionSource.getSessionFactory().create(), then manage
transactions and all objects in that session yourself.
Kalle
On Thu, Jul 22, 2010 at 9:38 AM, Jim O'Callaghan <jc...@yahoo.co.uk> wrote:
> I do get direct access to the session from the under a very specific
> circumstance to allow me to commit a separate transaction unconditionally,
> to facilitate keeping a pre-allocated batch of keys in memory - I can't have
> this transaction rolled back due to a problem somewhere else, or I am left
> with keys that the application thinks are available, but in reality the
> sequence hasn't been updated in the database due to a rollback. The new
> session is created using session.getSessionFactory().openSession() within a
> single method invocation, which I'm guessing leaves me open to thread safety
> issues. I'm going to rearrange it to make it more service based. I think
> this is just down to bad coding practice.
>
> Regards,
> Jim.
>
> -----Original Message-----
> From: Josh Canfield [mailto:joshcanfield@gmail.com]
> Sent: 22 July 2010 16:25
> To: Tapestry users
> Subject: Re: non thread safe access to session
>
>> I do however have some buried code where I force a transaction to commit
> to allow me to assign some non-customer facing entity keys in batches, to
> reduce db hits - this is probably causing the problem - I'll synchronize
> that as it's not called too often and hopefully that will do it. Thanks for
> the tips guys.
>
> I'm curious why you'd need to synchronize anything to do what you've
> described. You shouldn't be getting any cross-thread access to a single
> session.
>
> -- Josh
>
> On Jul 22, 2010, at 1:16 AM, "Jim O'Callaghan" <jc...@yahoo.co.uk>
> wrote:
>
>> Jonathon, Howard,
>>
>> Thanks for the responses. I'm leaning towards Howard's explanation. The
> processes are accessing newly created / persisted objects so I don't think
> sharing attached objects across more than one session should arise. I do
> however have some buried code where I force a transaction to commit to allow
> me to assign some non-customer facing entity keys in batches, to reduce db
> hits - this is probably causing the problem - I'll synchronize that as it's
> not called too often and hopefully that will do it. Thanks for the tips
> guys.
>>
>> Regards,
>> Jim.
>>
>> -----Original Message-----
>> From: Jonathan Barker [mailto:jonathan.theitguy@gmail.com]
>> Sent: 22 July 2010 02:31
>> To: Tapestry users
>> Subject: Re: non thread safe access to session
>>
>> Jim,
>>
>> I have vague recollections of hitting this before.
>>
>> IIRC, each hibernate object knows the Session that it is associated with.
>> So, if an object is associated with Session A on Thread A, and you modify
>> that object from Thread B, then Session A now has to manage changes made
>> from a different thread, which presents lots of challenges.
>>
>> So, I think it's not so much about your handling of the Sessions, as it is
>> about handling session-managed objects that get accessed from different
>> threads.
>>
>> Can you detach your objects before allowing other threads to access them?
>>
>> Regards,
>>
>> Jonathan
>>
>>
>> On Wed, Jul 21, 2010 at 1:29 PM, Jim O'Callaghan
> <jc...@yahoo.co.uk>wrote:
>>
>>> Yep Thiago, it's Tapestry-Hibernate creating the sessions. My situation
>>> might be a little contrived, but I'm concerned it might happen to
>>> end-users, as I don't fully understand why it's happening.
>>>
>>> Regards,
>>> Jim.
>>>
>>> -----Original Message-----
>>> From: Thiago H. de Paula Figueiredo [mailto:thiagohp@gmail.com]
>>> Sent: 21 July 2010 18:22
>>> To: Tapestry users
>>> Subject: Re: non thread safe access to session
>>>
>>> On Wed, 21 Jul 2010 13:58:15 -0300, Jim O'Callaghan
>>> <jc...@yahoo.co.uk> wrote:
>>>
>>>> Hi Thiago,
>>>
>>> Hi, Jim!
>>>
>>>> I'm talking about the hibernate session - I'm injecting it into the
>>>> constructor of Service B at bind time. I thought Tapestry would treat
>>>> the service as a thread safe singleton and control access to method
>>>> calls on it accordingly?
>>>
>>> Tapestry-IoC doesn't synchronize method calls. How are you building the
>>> sessions? Tapestry-Hibernate?
>>>
>>> --
>>> Thiago H. de Paula Figueiredo
>>> Independent Java, Apache Tapestry 5 and Hibernate consultant, developer,
>>> and instructor
>>> Owner, Ars Machina Tecnologia da Informa??o Ltda.
>>> http://www.arsmachina.com.br
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>>
>>>
>>
>>
>> --
>> Jonathan Barker
>> ITStrategic
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: users-help@tapestry.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
RE: non thread safe access to session
Posted by Jim O'Callaghan <jc...@yahoo.co.uk>.
I do get direct access to the session from the under a very specific
circumstance to allow me to commit a separate transaction unconditionally,
to facilitate keeping a pre-allocated batch of keys in memory - I can't have
this transaction rolled back due to a problem somewhere else, or I am left
with keys that the application thinks are available, but in reality the
sequence hasn't been updated in the database due to a rollback. The new
session is created using session.getSessionFactory().openSession() within a
single method invocation, which I'm guessing leaves me open to thread safety
issues. I'm going to rearrange it to make it more service based. I think
this is just down to bad coding practice.
Regards,
Jim.
-----Original Message-----
From: Josh Canfield [mailto:joshcanfield@gmail.com]
Sent: 22 July 2010 16:25
To: Tapestry users
Subject: Re: non thread safe access to session
> I do however have some buried code where I force a transaction to commit
to allow me to assign some non-customer facing entity keys in batches, to
reduce db hits - this is probably causing the problem - I'll synchronize
that as it's not called too often and hopefully that will do it. Thanks for
the tips guys.
I'm curious why you'd need to synchronize anything to do what you've
described. You shouldn't be getting any cross-thread access to a single
session.
-- Josh
On Jul 22, 2010, at 1:16 AM, "Jim O'Callaghan" <jc...@yahoo.co.uk>
wrote:
> Jonathon, Howard,
>
> Thanks for the responses. I'm leaning towards Howard's explanation. The
processes are accessing newly created / persisted objects so I don't think
sharing attached objects across more than one session should arise. I do
however have some buried code where I force a transaction to commit to allow
me to assign some non-customer facing entity keys in batches, to reduce db
hits - this is probably causing the problem - I'll synchronize that as it's
not called too often and hopefully that will do it. Thanks for the tips
guys.
>
> Regards,
> Jim.
>
> -----Original Message-----
> From: Jonathan Barker [mailto:jonathan.theitguy@gmail.com]
> Sent: 22 July 2010 02:31
> To: Tapestry users
> Subject: Re: non thread safe access to session
>
> Jim,
>
> I have vague recollections of hitting this before.
>
> IIRC, each hibernate object knows the Session that it is associated with.
> So, if an object is associated with Session A on Thread A, and you modify
> that object from Thread B, then Session A now has to manage changes made
> from a different thread, which presents lots of challenges.
>
> So, I think it's not so much about your handling of the Sessions, as it is
> about handling session-managed objects that get accessed from different
> threads.
>
> Can you detach your objects before allowing other threads to access them?
>
> Regards,
>
> Jonathan
>
>
> On Wed, Jul 21, 2010 at 1:29 PM, Jim O'Callaghan
<jc...@yahoo.co.uk>wrote:
>
>> Yep Thiago, it's Tapestry-Hibernate creating the sessions. My situation
>> might be a little contrived, but I'm concerned it might happen to
>> end-users, as I don't fully understand why it's happening.
>>
>> Regards,
>> Jim.
>>
>> -----Original Message-----
>> From: Thiago H. de Paula Figueiredo [mailto:thiagohp@gmail.com]
>> Sent: 21 July 2010 18:22
>> To: Tapestry users
>> Subject: Re: non thread safe access to session
>>
>> On Wed, 21 Jul 2010 13:58:15 -0300, Jim O'Callaghan
>> <jc...@yahoo.co.uk> wrote:
>>
>>> Hi Thiago,
>>
>> Hi, Jim!
>>
>>> I'm talking about the hibernate session - I'm injecting it into the
>>> constructor of Service B at bind time. I thought Tapestry would treat
>>> the service as a thread safe singleton and control access to method
>>> calls on it accordingly?
>>
>> Tapestry-IoC doesn't synchronize method calls. How are you building the
>> sessions? Tapestry-Hibernate?
>>
>> --
>> Thiago H. de Paula Figueiredo
>> Independent Java, Apache Tapestry 5 and Hibernate consultant, developer,
>> and instructor
>> Owner, Ars Machina Tecnologia da Informa??o Ltda.
>> http://www.arsmachina.com.br
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: users-help@tapestry.apache.org
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: users-help@tapestry.apache.org
>>
>>
>
>
> --
> Jonathan Barker
> ITStrategic
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: non thread safe access to session
Posted by Josh Canfield <jo...@gmail.com>.
> I do however have some buried code where I force a transaction to commit to allow me to assign some non-customer facing entity keys in batches, to reduce db hits - this is probably causing the problem - I'll synchronize that as it's not called too often and hopefully that will do it. Thanks for the tips guys.
I'm curious why you'd need to synchronize anything to do what you've described. You shouldn't be getting any cross-thread access to a single session.
-- Josh
On Jul 22, 2010, at 1:16 AM, "Jim O'Callaghan" <jc...@yahoo.co.uk> wrote:
> Jonathon, Howard,
>
> Thanks for the responses. I'm leaning towards Howard's explanation. The processes are accessing newly created / persisted objects so I don't think sharing attached objects across more than one session should arise. I do however have some buried code where I force a transaction to commit to allow me to assign some non-customer facing entity keys in batches, to reduce db hits - this is probably causing the problem - I'll synchronize that as it's not called too often and hopefully that will do it. Thanks for the tips guys.
>
> Regards,
> Jim.
>
> -----Original Message-----
> From: Jonathan Barker [mailto:jonathan.theitguy@gmail.com]
> Sent: 22 July 2010 02:31
> To: Tapestry users
> Subject: Re: non thread safe access to session
>
> Jim,
>
> I have vague recollections of hitting this before.
>
> IIRC, each hibernate object knows the Session that it is associated with.
> So, if an object is associated with Session A on Thread A, and you modify
> that object from Thread B, then Session A now has to manage changes made
> from a different thread, which presents lots of challenges.
>
> So, I think it's not so much about your handling of the Sessions, as it is
> about handling session-managed objects that get accessed from different
> threads.
>
> Can you detach your objects before allowing other threads to access them?
>
> Regards,
>
> Jonathan
>
>
> On Wed, Jul 21, 2010 at 1:29 PM, Jim O'Callaghan <jc...@yahoo.co.uk>wrote:
>
>> Yep Thiago, it's Tapestry-Hibernate creating the sessions. My situation
>> might be a little contrived, but I'm concerned it might happen to
>> end-users, as I don't fully understand why it's happening.
>>
>> Regards,
>> Jim.
>>
>> -----Original Message-----
>> From: Thiago H. de Paula Figueiredo [mailto:thiagohp@gmail.com]
>> Sent: 21 July 2010 18:22
>> To: Tapestry users
>> Subject: Re: non thread safe access to session
>>
>> On Wed, 21 Jul 2010 13:58:15 -0300, Jim O'Callaghan
>> <jc...@yahoo.co.uk> wrote:
>>
>>> Hi Thiago,
>>
>> Hi, Jim!
>>
>>> I'm talking about the hibernate session - I'm injecting it into the
>>> constructor of Service B at bind time. I thought Tapestry would treat
>>> the service as a thread safe singleton and control access to method
>>> calls on it accordingly?
>>
>> Tapestry-IoC doesn't synchronize method calls. How are you building the
>> sessions? Tapestry-Hibernate?
>>
>> --
>> Thiago H. de Paula Figueiredo
>> Independent Java, Apache Tapestry 5 and Hibernate consultant, developer,
>> and instructor
>> Owner, Ars Machina Tecnologia da Informa??o Ltda.
>> http://www.arsmachina.com.br
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: users-help@tapestry.apache.org
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: users-help@tapestry.apache.org
>>
>>
>
>
> --
> Jonathan Barker
> ITStrategic
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
RE: non thread safe access to session
Posted by Jim O'Callaghan <jc...@yahoo.co.uk>.
Jonathon, Howard,
Thanks for the responses. I'm leaning towards Howard's explanation. The processes are accessing newly created / persisted objects so I don't think sharing attached objects across more than one session should arise. I do however have some buried code where I force a transaction to commit to allow me to assign some non-customer facing entity keys in batches, to reduce db hits - this is probably causing the problem - I'll synchronize that as it's not called too often and hopefully that will do it. Thanks for the tips guys.
Regards,
Jim.
-----Original Message-----
From: Jonathan Barker [mailto:jonathan.theitguy@gmail.com]
Sent: 22 July 2010 02:31
To: Tapestry users
Subject: Re: non thread safe access to session
Jim,
I have vague recollections of hitting this before.
IIRC, each hibernate object knows the Session that it is associated with.
So, if an object is associated with Session A on Thread A, and you modify
that object from Thread B, then Session A now has to manage changes made
from a different thread, which presents lots of challenges.
So, I think it's not so much about your handling of the Sessions, as it is
about handling session-managed objects that get accessed from different
threads.
Can you detach your objects before allowing other threads to access them?
Regards,
Jonathan
On Wed, Jul 21, 2010 at 1:29 PM, Jim O'Callaghan <jc...@yahoo.co.uk>wrote:
> Yep Thiago, it's Tapestry-Hibernate creating the sessions. My situation
> might be a little contrived, but I'm concerned it might happen to
> end-users, as I don't fully understand why it's happening.
>
> Regards,
> Jim.
>
> -----Original Message-----
> From: Thiago H. de Paula Figueiredo [mailto:thiagohp@gmail.com]
> Sent: 21 July 2010 18:22
> To: Tapestry users
> Subject: Re: non thread safe access to session
>
> On Wed, 21 Jul 2010 13:58:15 -0300, Jim O'Callaghan
> <jc...@yahoo.co.uk> wrote:
>
> > Hi Thiago,
>
> Hi, Jim!
>
> > I'm talking about the hibernate session - I'm injecting it into the
> > constructor of Service B at bind time. I thought Tapestry would treat
> > the service as a thread safe singleton and control access to method
> > calls on it accordingly?
>
> Tapestry-IoC doesn't synchronize method calls. How are you building the
> sessions? Tapestry-Hibernate?
>
> --
> Thiago H. de Paula Figueiredo
> Independent Java, Apache Tapestry 5 and Hibernate consultant, developer,
> and instructor
> Owner, Ars Machina Tecnologia da Informa??o Ltda.
> http://www.arsmachina.com.br
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
--
Jonathan Barker
ITStrategic
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: non thread safe access to session
Posted by Jonathan Barker <jo...@gmail.com>.
Jim,
I have vague recollections of hitting this before.
IIRC, each hibernate object knows the Session that it is associated with.
So, if an object is associated with Session A on Thread A, and you modify
that object from Thread B, then Session A now has to manage changes made
from a different thread, which presents lots of challenges.
So, I think it's not so much about your handling of the Sessions, as it is
about handling session-managed objects that get accessed from different
threads.
Can you detach your objects before allowing other threads to access them?
Regards,
Jonathan
On Wed, Jul 21, 2010 at 1:29 PM, Jim O'Callaghan <jc...@yahoo.co.uk>wrote:
> Yep Thiago, it's Tapestry-Hibernate creating the sessions. My situation
> might be a little contrived, but I'm concerned it might happen to
> end-users, as I don't fully understand why it's happening.
>
> Regards,
> Jim.
>
> -----Original Message-----
> From: Thiago H. de Paula Figueiredo [mailto:thiagohp@gmail.com]
> Sent: 21 July 2010 18:22
> To: Tapestry users
> Subject: Re: non thread safe access to session
>
> On Wed, 21 Jul 2010 13:58:15 -0300, Jim O'Callaghan
> <jc...@yahoo.co.uk> wrote:
>
> > Hi Thiago,
>
> Hi, Jim!
>
> > I'm talking about the hibernate session - I'm injecting it into the
> > constructor of Service B at bind time. I thought Tapestry would treat
> > the service as a thread safe singleton and control access to method
> > calls on it accordingly?
>
> Tapestry-IoC doesn't synchronize method calls. How are you building the
> sessions? Tapestry-Hibernate?
>
> --
> Thiago H. de Paula Figueiredo
> Independent Java, Apache Tapestry 5 and Hibernate consultant, developer,
> and instructor
> Owner, Ars Machina Tecnologia da Informa��o Ltda.
> http://www.arsmachina.com.br
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
--
Jonathan Barker
ITStrategic
RE: non thread safe access to session
Posted by Jim O'Callaghan <jc...@yahoo.co.uk>.
Yep Thiago, it's Tapestry-Hibernate creating the sessions. My situation might be a little contrived, but I'm concerned it might happen to end-users, as I don't fully understand why it's happening.
Regards,
Jim.
-----Original Message-----
From: Thiago H. de Paula Figueiredo [mailto:thiagohp@gmail.com]
Sent: 21 July 2010 18:22
To: Tapestry users
Subject: Re: non thread safe access to session
On Wed, 21 Jul 2010 13:58:15 -0300, Jim O'Callaghan
<jc...@yahoo.co.uk> wrote:
> Hi Thiago,
Hi, Jim!
> I'm talking about the hibernate session - I'm injecting it into the
> constructor of Service B at bind time. I thought Tapestry would treat
> the service as a thread safe singleton and control access to method
> calls on it accordingly?
Tapestry-IoC doesn't synchronize method calls. How are you building the
sessions? Tapestry-Hibernate?
--
Thiago H. de Paula Figueiredo
Independent Java, Apache Tapestry 5 and Hibernate consultant, developer,
and instructor
Owner, Ars Machina Tecnologia da Informa��o Ltda.
http://www.arsmachina.com.br
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: non thread safe access to session
Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
On Wed, 21 Jul 2010 13:58:15 -0300, Jim O'Callaghan
<jc...@yahoo.co.uk> wrote:
> Hi Thiago,
Hi, Jim!
> I'm talking about the hibernate session - I'm injecting it into the
> constructor of Service B at bind time. I thought Tapestry would treat
> the service as a thread safe singleton and control access to method
> calls on it accordingly?
Tapestry-IoC doesn't synchronize method calls. How are you building the
sessions? Tapestry-Hibernate?
--
Thiago H. de Paula Figueiredo
Independent Java, Apache Tapestry 5 and Hibernate consultant, developer,
and instructor
Owner, Ars Machina Tecnologia da Informação Ltda.
http://www.arsmachina.com.br
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
RE: non thread safe access to session
Posted by Jim O'Callaghan <jc...@yahoo.co.uk>.
Hi Thiago,
I'm talking about the hibernate session - I'm injecting it into the constructor of Service B at bind time. I thought Tapestry would treat the service as a thread safe singleton and control access to method calls on it accordingly? Am I getting confused on that?
Regards,
Jim.
-----Original Message-----
From: Thiago H. de Paula Figueiredo [mailto:thiagohp@gmail.com]
Sent: 21 July 2010 17:38
To: Tapestry users
Subject: Re: non thread safe access to session
Are you talking about Tapestry sessions or Hibernate sessions? Hibernate
sessions should never be used at the same time by more than one thread.
--
Thiago H. de Paula Figueiredo
Independent Java, Apache Tapestry 5 and Hibernate consultant, developer,
and instructor
Owner, Ars Machina Tecnologia da Informa��o Ltda.
http://www.arsmachina.com.br
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: non thread safe access to session
Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
Are you talking about Tapestry sessions or Hibernate sessions? Hibernate
sessions should never be used at the same time by more than one thread.
--
Thiago H. de Paula Figueiredo
Independent Java, Apache Tapestry 5 and Hibernate consultant, developer,
and instructor
Owner, Ars Machina Tecnologia da Informação Ltda.
http://www.arsmachina.com.br
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: non thread safe access to session
Posted by Howard Lewis Ship <hl...@gmail.com>.
Certainly, I don't see this logic. What gets injected into both
service A and service B should by the perthread proxy to the Hibernate
Session service. This implements all the Session methods but delegates
to a per-thread instance that is discarded at the end of the request.
The thing to watch out for is if you try to acquire the *real*
Hibernate session object from the SessionManager service; this is not
proxied and is not thread safe. If you store somewhere, such as a
static field, or an instance field of a singleton service, or the
HttpSession, you are opening yourself up for some hurt!
On Wed, Jul 21, 2010 at 9:33 AM, Jim O'Callaghan <jc...@yahoo.co.uk> wrote:
> I have a service (service A) that creates some sample data, consisting of a
> reasonably detailed object graph where all the relations are cascaded. This
> service makes use of another service (service B) which manages the save of
> the parent entity. Service B has the hibernate session injected at bind
> time. I have service A called in a finite loop in the setup (@SetupRender)
> method of a scratch page I use for some dev testing. To cut a long story
> short, when playing around with the sample data creation, I found I was
> getting some "non thread safe access to session" type messages when I
> launched a second user session and hit the same scratch page. This doesn't
> happen if I mark the relevant method in service A as synchronized, but this
> brings with it a significant performance penalty. I'm a little concerned I
> may have a situation where in a high traffic scenario multiple users hitting
> the same service methods may get the same error. Can anyone reiterate the
> best practise approach for marking member fields / injected parameters as
> final or point me to a relevant posting on it around here - I'm sure
> something about marking things as final was brought up on the list not so
> long ago but for the life of me I can't find it. I'm not sure if it's
> relevant but I'm using T5.2.0-SNAPSHOT. Perhaps this isn't Tapestry relevant
> at all and is down to my use of Hibernate. Thanks.
>
>
>
> Regards,
>
> Jim.
>
>
--
Howard M. Lewis Ship
Creator of Apache Tapestry
The source for Tapestry training, mentoring and support. Contact me to
learn how I can get you up and productive in Tapestry fast!
(971) 678-5210
http://howardlewisship.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org