Menu
▾
▴
springframework-developer
|
From: <jue...@we...> - 2004-09-01 20:42:22
|
Well, that's what HibernateTemplate's FLUSH_EAGER mode is meant for: To = automatically flush right after each operation, even if a prebound = Session is used. I would generally recommend to use such a preconfigured = HibernateTemplate instance here, no matter if a shared one like in a = HibernateDaoSupport or a newly instantiated one for a given = SessionFactory. =20 I'm not keen on a flush operation on HibernateTemplate itself: That's = not really a data access operation like the other methods there, but = rather a method that just modifies the state of the transaction. If = someone doesn't like the approach with a preconfigured = HibernateTemplate, there's still the option of a custom = HibernateCallback, even if just for a save and a flush. =20 Juergen =20 ________________________________ Von: spr...@li... im Auftrag = von Colin Sampaleanu Gesendet: Mi 01.09.2004 17:34 An: spr...@li... Betreff: [Springframework-developer] flush() method on HibernateTemplate Juergen, We had a request on the forums (and I've seen this before) to add flush() as a method on HibernateTemplate. Of course, this would be completely useless (or superfluous) in the case there is no existing thread bound session (or at least an existing outer transaction to bind the new session to and keep it there afterwards). But most people do use HibernateTemplate in their DAOs with the expectation that the Session is already around or will be created and stay around, and it's probably reasonable to allow them to do a flush without having to use HibernateCallback, since they could have just done a one-off operation like save() and then want to ensure that changes go out, for example when combining with JDBC based operations in a DAO. What do you think? ------------------------------------------------------- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=3D5047&alloc_id=3D10808&op=3Dclick _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer |
|
From: <jue...@we...> - 2004-09-02 18:26:16
|
Have I missed the latest mail from Colin here? I can't see it on the = mailing list... Juergen -----Original Message----- From: spr...@li... [mailto:spr...@li...]On Behalf Of James Cook Sent: Thursday, September 02, 2004 8:11 PM To: spr...@li... Subject: RE: [Springframework-developer] flush() method on HibernateTemplate > -----Original Message----- > Of Colin Sampaleanu > In the end, I think it's somewhat contrived if some app has to > do a half dozen HibernateCallback cases where the only only operation > inside them is a flush() call. 2c. I don't have the code in fromt of me, but I believe we have been = using getSession().flush() in our DAO's when we needed this behavior. As Colin stated already, classes that extend HibernateDAOSupport probably don't = mind a Hibernate-specific functionality exposed in their superclass. I also = agree with him that it isn't the same thing as EAGER_FLUSH. ------------------------------------------------------- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_idP47&alloc_id=10808&op=3Dick _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer |
|
From: <jue...@we...> - 2004-09-02 21:19:41
|
OK, convinced. I've just added a "flush" method to = HibernateOperations/HibernateTemplate and JdoOperations/JdoTemplate, = with the latter delegating to the existing JdoDialect.flush method. =20 Juergen =20 ________________________________ Von: spr...@li... im Auftrag = von Colin Sampaleanu Gesendet: Do 02.09.2004 21:17 An: spr...@li... Betreff: Re: [Springframework-developer] flush() method on = HibernateTemplate Here it is again Juergen, Colin Sampaleanu wrote: > FLUSH_EAGER is not at all the same, in my opinion. When doing mixed > Hibernate based code (with JDBC or EJBs) I on a number of occasions > had to issue flushes to ensure something was safely available for the > other code, but it was certainly nothing I wanted even most of the > time (default FLUSH_EAGER)... And your typical DAO based on something > like HibernateDaoSupport doesn't usually have the concept of working > with multiple templates. > > I was originally kind of against the idea, especially given the fact > that in non Session bound to thread mode the operation would be > completely redundant. But at the end of the day, the template is used > by DAOs, DAOs are very aware of Hibernate specifics, and I think > there's nothing fundamentally that wrong with allowing an explicit > flush to be done in an easy fashion. I don't agree this operation is > really related to transaction state either. Whether that data is in > the Session cache or has gone out to the db, the transaction can > generally still commit or rollback with the same effect. And Hibernate > itself will on its own criteria also decide to flush the cache > sometimes, such as when you do a query. In the end, I think it's > somewhat contrived if some app has to do a half dozen > HibernateCallback cases where the only only operation inside them is a > flush() call. > > > j=FCrgen h=F6ller [werk3AT] wrote: > >> Well, that's what HibernateTemplate's FLUSH_EAGER mode is meant for: >> To automatically flush right after each operation, even if a prebound >> Session is used. I would generally recommend to use such a >> preconfigured HibernateTemplate instance here, no matter if a shared >> one like in a HibernateDaoSupport or a newly instantiated one for a >> given SessionFactory. >> >> I'm not keen on a flush operation on HibernateTemplate itself: That's >> not really a data access operation like the other methods there, but >> rather a method that just modifies the state of the transaction. If >> someone doesn't like the approach with a preconfigured >> HibernateTemplate, there's still the option of a custom >> HibernateCallback, even if just for a save and a flush. >> >> Juergen >> >> >> ________________________________ >> >> Von: spr...@li... im Auftrag >> von Colin Sampaleanu >> Gesendet: Mi 01.09.2004 17:34 >> An: spr...@li... >> Betreff: [Springframework-developer] flush() method on = HibernateTemplate >> >> >> >> Juergen, >> >> We had a request on the forums (and I've seen this before) to add >> flush() as a method on HibernateTemplate. Of course, this would be >> completely useless (or superfluous) in the case there is no existing >> thread bound session (or at least an existing outer transaction to = bind >> the new session to and keep it there afterwards). But most people do = use >> HibernateTemplate in their DAOs with the expectation that the Session = is >> already around or will be created and stay around, and it's probably >> reasonable to allow them to do a flush without having to use >> HibernateCallback, since they could have just done a one-off = operation >> like save() and then want to ensure that changes go out, for example >> when combining with JDBC based operations in a DAO. >> >> What do you think? > ------------------------------------------------------- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=3D5047&alloc_id=3D10808&op=3Dclick _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer |
|
From: Rod J. <ro...@in...> - 2004-09-03 20:06:39
|
Thanks. I've tended to implement my own in a subclass, but Spring should provide it... -----Original Message----- From: spr...@li... [mailto:spr...@li...] On Behalf = Of j=FCrgen h=F6ller [werk3AT] Sent: 02 September 2004 22:23 To: spr...@li... Subject: Re: [Springframework-developer] flush() method on = HibernateTemplate OK, convinced. I've just added a "flush" method to HibernateOperations/HibernateTemplate and JdoOperations/JdoTemplate, = with the latter delegating to the existing JdoDialect.flush method. =20 Juergen =20 _ |
|
From: Colin S. <col...@ex...> - 2004-09-02 02:43:49
|
FLUSH_EAGER is not at all the same, in my opinion. When doing mixed Hibernate based code (with JDBC or EJBs) I on a number of occasions had to issue flushes to ensure something was safely available for the other code, but it was certainly nothing I wanted even most of the time (default FLUSH_EAGER)... And your typical DAO based on something like HibernateDaoSupport doesn't usually have the concept of working with multiple templates. I was originally kind of against the idea, especially given the fact that in non Session bound to thread mode the operation would be completely redundant. But at the end of the day, the template is used by DAOs, DAOs are very aware of Hibernate specifics, and I think there's nothing fundamentally that wrong with allowing an explicit flush to be done in an easy fashion. I don't agree this operation is really related to transaction state either. Whether that data is in the Session cache or has gone out to the db, the transaction can generally still commit or rollback with the same effect. And Hibernate itself will on its own criteria also decide to flush the cache sometimes, such as when you do a query. In the end, I think it's somewhat contrived if some app has to do a half dozen HibernateCallback cases where the only only operation inside them is a flush() call. jürgen höller [werk3AT] wrote: >Well, that's what HibernateTemplate's FLUSH_EAGER mode is meant for: To automatically flush right after each operation, even if a prebound Session is used. I would generally recommend to use such a preconfigured HibernateTemplate instance here, no matter if a shared one like in a HibernateDaoSupport or a newly instantiated one for a given SessionFactory. > >I'm not keen on a flush operation on HibernateTemplate itself: That's not really a data access operation like the other methods there, but rather a method that just modifies the state of the transaction. If someone doesn't like the approach with a preconfigured HibernateTemplate, there's still the option of a custom HibernateCallback, even if just for a save and a flush. > >Juergen > > >________________________________ > >Von: spr...@li... im Auftrag von Colin Sampaleanu >Gesendet: Mi 01.09.2004 17:34 >An: spr...@li... >Betreff: [Springframework-developer] flush() method on HibernateTemplate > > > >Juergen, > >We had a request on the forums (and I've seen this before) to add >flush() as a method on HibernateTemplate. Of course, this would be >completely useless (or superfluous) in the case there is no existing >thread bound session (or at least an existing outer transaction to bind >the new session to and keep it there afterwards). But most people do use >HibernateTemplate in their DAOs with the expectation that the Session is >already around or will be created and stay around, and it's probably >reasonable to allow them to do a flush without having to use >HibernateCallback, since they could have just done a one-off operation >like save() and then want to ensure that changes go out, for example >when combining with JDBC based operations in a DAO. > >What do you think? > > |
|
From: James C. <jim...@do...> - 2004-09-02 18:13:09
|
> -----Original Message----- > Of Colin Sampaleanu > In the end, I think it's somewhat contrived if some app has to > do a half dozen HibernateCallback cases where the only only operation > inside them is a flush() call. 2c. I don't have the code in fromt of me, but I believe we have been = using getSession().flush() in our DAO's when we needed this behavior. As Colin stated already, classes that extend HibernateDAOSupport probably don't = mind a Hibernate-specific functionality exposed in their superclass. I also = agree with him that it isn't the same thing as EAGER_FLUSH. |
|
From: Colin S. <col...@ex...> - 2004-09-02 19:18:35
|
Here it is again Juergen, Colin Sampaleanu wrote: > FLUSH_EAGER is not at all the same, in my opinion. When doing mixed > Hibernate based code (with JDBC or EJBs) I on a number of occasions > had to issue flushes to ensure something was safely available for the > other code, but it was certainly nothing I wanted even most of the > time (default FLUSH_EAGER)... And your typical DAO based on something > like HibernateDaoSupport doesn't usually have the concept of working > with multiple templates. > > I was originally kind of against the idea, especially given the fact > that in non Session bound to thread mode the operation would be > completely redundant. But at the end of the day, the template is used > by DAOs, DAOs are very aware of Hibernate specifics, and I think > there's nothing fundamentally that wrong with allowing an explicit > flush to be done in an easy fashion. I don't agree this operation is > really related to transaction state either. Whether that data is in > the Session cache or has gone out to the db, the transaction can > generally still commit or rollback with the same effect. And Hibernate > itself will on its own criteria also decide to flush the cache > sometimes, such as when you do a query. In the end, I think it's > somewhat contrived if some app has to do a half dozen > HibernateCallback cases where the only only operation inside them is a > flush() call. > > > jürgen höller [werk3AT] wrote: > >> Well, that's what HibernateTemplate's FLUSH_EAGER mode is meant for: >> To automatically flush right after each operation, even if a prebound >> Session is used. I would generally recommend to use such a >> preconfigured HibernateTemplate instance here, no matter if a shared >> one like in a HibernateDaoSupport or a newly instantiated one for a >> given SessionFactory. >> >> I'm not keen on a flush operation on HibernateTemplate itself: That's >> not really a data access operation like the other methods there, but >> rather a method that just modifies the state of the transaction. If >> someone doesn't like the approach with a preconfigured >> HibernateTemplate, there's still the option of a custom >> HibernateCallback, even if just for a save and a flush. >> >> Juergen >> >> >> ________________________________ >> >> Von: spr...@li... im Auftrag >> von Colin Sampaleanu >> Gesendet: Mi 01.09.2004 17:34 >> An: spr...@li... >> Betreff: [Springframework-developer] flush() method on HibernateTemplate >> >> >> >> Juergen, >> >> We had a request on the forums (and I've seen this before) to add >> flush() as a method on HibernateTemplate. Of course, this would be >> completely useless (or superfluous) in the case there is no existing >> thread bound session (or at least an existing outer transaction to bind >> the new session to and keep it there afterwards). But most people do use >> HibernateTemplate in their DAOs with the expectation that the Session is >> already around or will be created and stay around, and it's probably >> reasonable to allow them to do a flush without having to use >> HibernateCallback, since they could have just done a one-off operation >> like save() and then want to ensure that changes go out, for example >> when combining with JDBC based operations in a DAO. >> >> What do you think? > |
