It just seems like the way our API is written and is used, the assumption is that changes made to a domain object are only persisted if a saveObject() service method is called. But by default Hibernate persists changes to any attached objects automatically, and we are struggling without complete success to stop "premature" flushes, which make the prior assumption false. I haven't read the API 2.0 notes, but my suggestion would be in 2.0 we give up on that assumption instead of trying to enforce it.
Mark ________________________________________ From: [email protected] [[email protected]] On Behalf Of Burke Mamlin [[email protected]] Sent: Friday, March 09, 2012 12:54 PM To: [email protected] Subject: Re: [OPENMRS-DEV] Hibernate flush mode Rafał, If calls the API are made within the "// don't call a save patient here" excerpt in Mark's example, isn't it likely that the change will be persisted if Hibernate chooses to flush at any point? It seems that both save() methods and Context.closeSession() should perform a flush – i.e., ensure Hibernate has a chance to save any unsaved changes. Then we can at least provide a guarantee that a save() method or closeSession() will avoid persisting changes. -Burke On Fri, Mar 9, 2012 at 12:23 PM, Rafal Korytkowski <[email protected]<mailto:[email protected]>> wrote: The problem in Mark's test is that when you call Context.closeSession() within a transaction (our unit tests are transactional by default) it only dettaches the session from the transaction manager and doesn't close or even clear the session. It's stored and attached again when you call Context.openSession(). If you call Context.clearSession() before Context.closeSession() then it'll work as you expect. Roger, Ben explained the problem with dettaching objects from Hibernate. Our domain objects are interconnected and lazily initialized and we would have to initialize them prior to dettaching from Hibernate. Sometimes a graph of objects that needs to be initialized is quite vast and it could kill performance. It would require some redesigning of our API and our business model classes, which is quite a big change. -Rafal On 9 March 2012 17:50, Friedman, Roger (CDC/CGH/DGHA) (CTR) <[email protected]<mailto:[email protected]>> wrote: > Rafa -- > Thanks for the spadework. > ConceptDAO contains a wealth of not so great ideas. I think working on > REST has made us more aware of subclasses and helper classes and how to > represent them. > Is it an option to have only the DAO layer deal with Hibernate-connected > objects, to have it serve disconnected objects on read and reconnect them on > write? Wouldn't that mean our services and the API would no longer be > engaged with the session and its cache? > Saludos, Roger > > -----Original Message----- > From: [email protected]<mailto:[email protected]> > [mailto:[email protected]<mailto:[email protected]>] On Behalf Of Rafal > Korytkowski > Sent: Friday, March 09, 2012 9:54 AM > To: > [email protected]<mailto:[email protected]> > Subject: [OPENMRS-DEV] Hibernate flush mode > > Hey, > > I have been experimenting with Hibernate flush modes recently. The motivation > was that we experienced premature flushes triggered by Hibernate while > retrieving data from the DB, which made us temporarily switch from > FlushMode.AUTO to FlushMode.COMMIT or MANUAL to execute some parts of code > like validation. > > The initial attempt for a more general solution was TRUNK-3069, which > switched from the AUTO to COMMIT mode for all transactions. The flush was > triggered by us around any method annotated with > @Transactional(readOnly=false), but not around @Transactional(readOnly=true). > It seemed like a good approach at first, but then I discovered TRUNK-3103. > The problem could be eventually resolved by annotating with @Transactional > dao methods, which we are considering. > > Anyway TRUNK-3069 disables much of Hibernate functionality to handle flushes > for us and now I think it is not how we should approach the problem. > > I believe we need to stay with the AUTO flush mode and tune it only when it > is needed. Unfortunately, we cannot change the flush mode in any other place > than the DAO layer where we have access to hibernate's session, whereas most > of the time we actually need to control it in the service layer. > > So far whenever we needed to execute a service method in the manual flush > mode our approach was to go down to the DAO layer, which resulted in such > strange constructions as in getDefaultConceptMapType [0], where we put in the > DAO layer code that really belonged to the service layer. > > We have a few possibilities to deal with that. > > 1. We continue to handle the flush issue in DAOs the way it was before. > 2. We have something like CustomSessionFlushTask [1]. > 3. We have Context.getFlushMode() and Context.setFlushMode(flushMode). > We need our own FlushMode enum so that we don't introduce a dependency on > Hibernate in the service layer. > 4. We have @ManualFlush annotation to annotate service methods that we want > to explicitly execute in the manual flush mode. It's a more elegant variation > of 2., but slightly less useful since it requires to create a dedicated > method. For instance we have the getConcept method and if we want it to be > executed in one place only in the manual flush mode we need to create a > second method getConceptInManualFlush for the purpose of annotating it with > @ManualFlush. > > I am really curious what do you think or if there is anyone who has more > experience with that. > > [0] - > https://source.openmrs.org/browse/~br=1.9.x/OpenMRS/branches/1.9.x/api/src/main/java/org/openmrs/api/db/hibernate/HibernateConceptDAO.java?r=26243 > [1] - > https://source.openmrs.org/browse/~br=trunk/Modules/metadatasharing/trunk/src/org/openmrs/module/metadatasharing/api/db/hibernate/CustomSessionFlushTask.java?r=26268 > > -Rafal > > _________________________________________ > > To unsubscribe from OpenMRS Developers' mailing list, send an e-mail to > [email protected]<mailto:[email protected]> with "SIGNOFF > openmrs-devel-l" in the body (not the subject) of your e-mail. > > [mailto:[email protected]<mailto:[email protected]>?body=SIGNOFF%20openmrs-devel-l] _________________________________________ To unsubscribe from OpenMRS Developers' mailing list, send an e-mail to [email protected]<mailto:[email protected]> with "SIGNOFF openmrs-devel-l" in the body (not the subject) of your e-mail. [mailto:[email protected]<mailto:[email protected]>?body=SIGNOFF%20openmrs-devel-l] ________________________________ 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]
