> 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" <jc1000...@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.theit...@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 <jc1000...@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:thiag...@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 >> <jc1000...@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-unsubscr...@tapestry.apache.org >> For additional commands, e-mail: users-h...@tapestry.apache.org >> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org >> For additional commands, e-mail: users-h...@tapestry.apache.org >> >> > > > -- > Jonathan Barker > ITStrategic > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org > For additional commands, e-mail: users-h...@tapestry.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
