Thanks Rafal--I'd been running into similar issues recently. I wasn't quite sure how nested transactions work. Do we have a wiki page on Hibernate and transactions?
This described more about the difference between a commit and flush: http://www.coderanch.com/t/218534/ORM/java/Difference-between-commit-flush-Hibernate Mark -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Rafal Korytkowski Sent: Wednesday, January 25, 2012 8:47 AM To: [email protected] Subject: Re: [OPENMRS-DEV] Hibernate Sessions Issue Please make sure that you're not starting the other thread before commit in the first one. Flushing session won't help since uncommitted reads are not visible in other transactions. In order for the commit to happen you need to leave the service method annotated with @Transactional. Note that if you call service methods recursively then you need to leave all of them since a transaction is started for the first call and will be committed only if that one returns. You can annotate DAOs with @Transactional if you prefer. -Rafal On 25 January 2012 14:12, McKee, Steven Jay <[email protected]> wrote: > I’m calling flush session before the second thread is even created. > Is the flush session call on a thread of its own? Why else would the > data not be there if I explicitly tell it to flush? How would you go > about making the second thread wait on the first to successfully flush? > > > > Thanks, > > Steve > > > > From: [email protected] [mailto:[email protected]] On Behalf Of Wyclif > Luyima > Sent: Tuesday, January 24, 2012 10:16 PM > > > To: [email protected] > Subject: Re: [OPENMRS-DEV] Hibernate Sessions Issue > > > > I'm not sure how you are coding this out, but of course what i said > can fail if the second thread tries to accesses the created > patientState before the first has actually flushed its session . > Basically ensure, you can make the second thread wait on the first to > guarantee that the session is flushed. > > > > Wyclif > > On Tue, Jan 24, 2012 at 9:26 PM, McKee, Steven Jay <[email protected]> > wrote: > > I was able to give flushing session one a try, but it did not solve > the problem. I’m still running into conditions where the spawned > thread intermittently does not know about the PatientState object > created in session one. > > > > Steve > > > > From: McKee, Steven Jay > Sent: Friday, December 30, 2011 10:24 AM > To: '[email protected]' > Subject: RE: [OPENMRS-DEV] Hibernate Sessions Issue > > > > Thanks, Wyclif! I’ll give this a try. > > > > Steve > > > > From: [email protected] [mailto:[email protected]] On Behalf Of Wyclif > Luyima > Sent: Thursday, December 29, 2011 4:45 PM > To: [email protected] > Subject: Re: [OPENMRS-DEV] Hibernate Sessions Issue > > > > The hibernate session is associated to the same thread as that of the > authenticated user's context, so if any updates/inserts in one > thread are not yet persisted to the DB until the session is flushed, > implying the changes won't be visible to other threads. You need to > ensure that the first session is flushed, you can manually call > Context.flushSession() on the first thread before starting the second thread. > > > > Wyclif > > On Thu, Dec 29, 2011 at 3:56 PM, Burke Mamlin > <[email protected]> > wrote: > > Are you creating the PatientState within an application session in the > first session – calling openSession & closeSession on either end? > When you saw then session one "inserts a new PatientSate", that means > that you are creating the new object through the API, right? > > > > FWIW, while we're subject to Hibernate unpredictability until our API > is rewritten, having changes to objects sometimes persisted before > asking the API to save them is a smaller problem than calling create > or save on an object and not having those changes reliably persisted. > If the latter is happening (as your issue suggests), then we need to fix it. > > > > -Burke > > > > On Thu, Dec 29, 2011 at 11:30 AM, McKee, Steven Jay > <[email protected]> > wrote: > > I’m currently running OpenMRS 1.7, and I’m seeing an intermittent > issue across Hibernate sessions in our CHICA code: > > > > 1. Session one inserts a new PatientState (CHICA specific > table/object). > > 2. A new thread is created to do some processing on the PatientState. > The patient state ID is passed to the thread. > > 3. Session two is created in the new thread and tries to get a > PatientState object based on the patient state ID. > > 4. The PatientState object is coming back null. > > > > It seems as though session one has not committed the new patient state > and session two is trying to access it. What is the best Hibernate > mechanism to use to ensure the patient state is committed to the > database before session two tries to access it? Keep in mind the > PatientState object is being accessed outside the DAO layer. > > > > Thanks, > > Steve > > > > ________________________________ > > Click here to unsubscribe from OpenMRS Developers' mailing list > > > > ________________________________ > > Click here to unsubscribe from OpenMRS Developers' mailing list > > > > ________________________________ > > Click here to unsubscribe from OpenMRS Developers' mailing list > > ________________________________ > > Click here to unsubscribe from OpenMRS Developers' mailing list > > > > ________________________________ > > Click here to unsubscribe from OpenMRS Developers' mailing list > > ________________________________ > Click here to unsubscribe from OpenMRS Developers' mailing list _________________________________________ To unsubscribe from OpenMRS Developers' mailing list, send an e-mail to [email protected] with "SIGNOFF openmrs-devel-l" in the body (not the subject) of your e-mail. [mailto:[email protected]?body=SIGNOFF%20openmrs-devel-l]
