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:joshcanfi...@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" <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 --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
