Jason:
What happens if some *accidentally* calls getReadOnly() and performs a write?



Cheers, matthew

On Nov 14, 2003, at 8:01 PM, Jason Carreira wrote:

Ok... Looking back at what we did here (and bugging Gavin)...

We always set mySession.setFlushMode(FlushMode.NEVER);

And have a flag that is set in the getReadWrite() that tells it to
manually flush() on dispose, otherwise it doesn't flush at all, which
saves it from having to check the objects.

Jason

-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On
Behalf Of Eric Pugh
Sent: Friday, November 14, 2003 5:51 PM
To: [EMAIL PROTECTED]
Subject: RE: [OS-webwork] Hibernate Session as Request Scoped
Component


Hibernate is smart enough to know when to do the flush.. Yes, it has to check internally that nothing changed, but you would be doing that anyway. So, when you call the flush command, Hibernate then figures out what needs to be saved, and if nothing needs to be saved, then it won't...

Eric

-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
Behalf Of
Jason Carreira
Sent: Friday, November 14, 2003 8:50 PM
To: [EMAIL PROTECTED]
Subject: RE: [OS-webwork] Hibernate Session as Request Scoped
Component


I think this is a good solution, except I think you forgot
to save the
Session if it's null. I would optimize it by having two methods:

getReadOnlySession
getReadWriteSession

Which both return the same Session, but getReadWriteSession
sets a flag
to do the flush()... If the flag is not set, you can skip the
flush and
roll back the transaction.

Jason

-----Original Message-----
From: Matthew E. Porter [mailto:[EMAIL PROTECTED]
Sent: Friday, November 14, 2003 12:16 PM
To: [EMAIL PROTECTED]
Subject: [OS-webwork] Hibernate Session as Request Scoped
Component


Instead of using a ThreadLocal Hibernate Session, has
anyone played
with having a HibernateSessionProvider component at the
request scope?
Here is how I would envision the code:

public class HibernateSessionProvider implements SessionProvider,
Disposable {
     private SessionFactoryProvider sessionFactoryProvider;
     private Session session;

     public SessionFactoryProvider getSessionFactoryProvider() {
         return this.sessionFactoryProvider;
     }

     public void setSessionFactoryProvider(SessionFactoryProvider
sessionFactoryProvider) {
         this.sessionFactoryProvider = sessionFactoryProvider;
     }

     public Session getSession() throws PersistenceException {
         if ((this.session == null) || (!this.session.isOpen())) {
             try {
                 return
this.sessionFactoryProvider.getSessionFactory().openSession();
             } catch (HibernateException he) {
                 throw new
PersistenceException("HibernateException
caught building hibernate hibernate", he);
             }
         }

         return this.session;
     }

     public void dispose() {
         if ((this.session != null) && (this.session.isOpen()) &&
(this.session.isConnected()) {
             try {
             this.session.flush();
             this.session.connection().commit();
             this.session.close();
             } catch (Exception e) {
                 // do something
             }
         }

     }
}


Is there anything wrong with doing it this way? All of the components needing a Hibernate session (Persistence Manager and DAOs)
are scoped
at the same level. SessionFactoryProvider is another
component but
scoped at the application.


Cheers, matthew



-------------------------------------------------------
This SF. Net email is sponsored by: GoToMyPC
GoToMyPC is the fast, easy and secure way to access your
computer from any Web browser or wireless device. Click here
to Try it Free!
https://www.gotomypc.com/tr/OSDN/AW/Q4_2003/t/g22lp?Target=mm/
g22lp.tmpl
_______________________________________________
Opensymphony-webwork mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork


------------------------------------------------------- This SF. Net email is sponsored by: GoToMyPC GoToMyPC is the fast, easy and secure way to access your
computer from
any Web browser or wireless device. Click here to Try it Free!
https://www.gotomypc.com/tr/OSDN/AW/Q4_2003/t/g22lp?Target=mm/
g22lp.tmpl
_______________________________________________
Opensymphony-webwork mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork



-------------------------------------------------------
This SF. Net email is sponsored by: GoToMyPC
GoToMyPC is the fast, easy and secure way to access your computer from
any Web browser or wireless device. Click here to Try it Free!
https://www.gotomypc.com/tr/OSDN/AW/Q4_2003/t/g22lp?Target=mm/ g22lp.tmpl
_______________________________________________
Opensymphony-webwork mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork



------------------------------------------------------- This SF. Net email is sponsored by: GoToMyPC GoToMyPC is the fast, easy and secure way to access your computer from any Web browser or wireless device. Click here to Try it Free! https://www.gotomypc.com/tr/OSDN/AW/Q4_2003/t/g22lp?Target=mm/g22lp.tmpl _______________________________________________ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork

Reply via email to