To put it simple start the other thread in a place where there's no transaction like outside of any service method.
-Rafal On 25 January 2012 14:47, Rafal Korytkowski <[email protected]> wrote: > 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]
