Hi Matt, Hi Werner,
I agree with point 1 of first message of this thread to offer a close() method. In most cases it is good practis to offer dispose() methods where you create something or close() methods where you open connections.
I'm not that shure how to proceed with the second issue. Should we try to resolve missbehaves of all different databases? Especially this commit rollback issue isn't that easy as we don't know what happens if castor is part of a distributed transaction. How do other persistence engines handle this?
As a starting point I would first request the postgres team to change that.
Ralf
Werner Guttmann schrieb:
Matt,
I've CCed [email protected], so that others interested can share their views as well. For comments, please see inline ...
Werner
wg> -----Original Message-----
wg> From: Matt Harvey [mailto:[EMAIL PROTECTED]
wg> Sent: Tuesday, May 03, 2005 10:37 PM
wg> To: Werner Guttmann
wg> Subject: RE: [castor-user] [JDO] Two questions
wg> wg> wg> Hi Werner,
wg> wg> (I wasn't sure the rest of the list would be interested in wg> the details.)
wg> wg> There seem to be a lot of places where conn.commit() is wg> called (about 16 or so, although only 2 are outside of the test wg> code). The cleanest thing would be to replace those calls with wg> some kind of ConnectionUtilities.commit(conn) which:
wg> wg> public static void commit(Connection conn)
wg> throws SQLException
wg> {
wg> conn.commit();
wg> conn.setAutoCommit(true);
wg> }
wg> wg> I think this would be safe because you always seem to be calling
wg> setAutoCommit(false) when starting to use a connection. Oh, and of
wg> course there would have to be a corresponding rollback() method that
wg> also setAutoCommit(true).
wg> wg> public static void rollback(Connection conn)
wg> throws SQLException
wg> {
wg> conn.rollback();
wg> conn.setAutoCommit(true);
wg> }
wg> wg> Now, it may not be worth the effort just to support wg> PostgresSQL 7.4, but I imagine there's some general value in resetting wg> the value of auto-commit after you're done using a connection.
Actually, this is the point where I don't really feel comfortable. I am not really eager to introduce code to the system that is specific to one RDBMS (postgreSQL in this case). Whilst I agree with you that this very kind of funtionality should be introduced to Castor, it needs to be in a different place. Having said that, what we need is to introduce an observer pattern where e.g. a method of a interface/class to be created will be invoked upon commit/rollback. And that's exactly where your code needs to go, a postgreSQL-specific class that deals with these issues. There's already the PersistenceFactory and all the RDBMS-specific implementatiosn out there, but I am not sure whether this is the right place to add such functionality.
wg> wg> wg> wg> -----Original Message-----
wg> From: Werner Guttmann [mailto:[EMAIL PROTECTED] wg> Sent: Tuesday, May 03, 2005 4:02 AM
wg> To: [email protected]
wg> Subject: RE: [castor-user] [JDO] Two questions
wg> wg> Matt,
wg> wg> Castor does currently not offer a life-cycle method for wg> releasing its
wg> resources, but as we have been recently talking about this, wg> I am sure
wg> this feature will make it into one of the upcoming wg> releases. Al always,
wg> any contribution(s) would be welcomed.
wg> wg> Regards
wg> Werner
wg> wg> PS Wrt the postgreSQL issue, can you please have a look at wg> the current
wg> codebase and let me know where and how you think this could wg> be added.
wg> wg> -----Original Message-----
wg> From: Matt Harvey [mailto:[EMAIL PROTECTED]
wg> Sent: Monday, May 02, 2005 7:35 PM
wg> To: [email protected]
wg> Subject: [castor-user] [JDO] Two questions
wg> wg> wg> Two questions regarding castor's interaction with a database:
wg> wg> 1) There doesn't seem to be a way to shut down the JDO wg> object. I'm using
wg> a pooling data source underneath it, and I would like a clean way to
wg> close down all of the connections in the pool. How is one wg> intended to
wg> indicate that a JDO object is no longer in use? No close() method?
wg> wg> wg> 2) We're using PostgreSQL 7.4 as our database, and their wg> implementation
wg> of setAutoCommit(false) is somewhat braindead. When wg> auto-commit is set
wg> to false, invoking commit() on a Connection causes the wg> driver to send
wg> "commit; begin;" and invoking rollback() on the Connection wg> causes it to
wg> send "rollback; begin;". wg> wg> In other words, it opens the next transaction after you commit your
wg> transaction. While this basically works, it means that you wg> end up with
wg> an open-ended transaction. This causes all kinds of problems. The
wg> solution is to always call setAutoCommit(true) after wg> calling commit. The
wg> Postgres driver sends an "end" when you set auto-commit to true. wg> wg> This is basically a bit of silliness in Postgres 7.4, but it would
wg> probably be worth looking at updating Castor to setAutoCommit(true)
wg> after its commit (since it always calls setAutoCommit(false) anyway.
wg> wg> wg> wg> Thanks!
wg>
