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.korho...@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 <jc1000...@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: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 > > --------------------------------------------------------------------- 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
