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<[email protected]?body=SIGNOFF%20openmrs-devel-l>from > OpenMRS Developers' mailing list > **** > > ** ** > ------------------------------ > > Click here to > unsubscribe<[email protected]?body=SIGNOFF%20openmrs-devel-l>from > OpenMRS Developers' mailing list > **** > > ** ** > ------------------------------ > > Click here to > unsubscribe<[email protected]?body=SIGNOFF%20openmrs-devel-l>from > OpenMRS Developers' mailing list > **** > ------------------------------ > Click here to > unsubscribe<[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]
