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]<mailto:[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]<mailto:[email protected]>' Subject: RE: [OPENMRS-DEV] Hibernate Sessions Issue Thanks, Wyclif! I'll give this a try. Steve From: [email protected]<mailto:[email protected]> [mailto:[email protected]]<mailto:[mailto:[email protected]]> On Behalf Of Wyclif Luyima Sent: Thursday, December 29, 2011 4:45 PM To: [email protected]<mailto:[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]<mailto:[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]<mailto:[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<mailto:[email protected]?body=SIGNOFF%20openmrs-devel-l> from OpenMRS Developers' mailing list ________________________________ Click here to unsubscribe<mailto:[email protected]?body=SIGNOFF%20openmrs-devel-l> from OpenMRS Developers' mailing list ________________________________ Click here to unsubscribe<mailto:[email protected]?body=SIGNOFF%20openmrs-devel-l> from OpenMRS Developers' mailing list ________________________________ Click here to unsubscribe<mailto:[email protected]?body=SIGNOFF%20openmrs-devel-l> from OpenMRS Developers' mailing list ________________________________ Click here to unsubscribe<mailto:[email protected]?body=SIGNOFF%20openmrs-devel-l> 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]
