Naturally, if there's a mechanism to behave differently based on the particular RDBMS implementation, that's where this should go!
-----Original Message----- From: Werner Guttmann [mailto:[EMAIL PROTECTED] Sent: Wednesday, May 04, 2005 3:32 AM To: Matt Harvey Cc: [email protected] Subject: RE: [castor-user] [JDO] Two questions 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 the wg> details.) wg> wg> There seem to be a lot of places where conn.commit() is called wg> (about 16 or so, although only 2 are outside of the test code). The wg> cleanest thing would be to replace those calls with some kind of wg> 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 PostgresSQL 7.4, wg> but I imagine there's some general value in resetting the value of wg> 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 releasing wg> its resources, but as we have been recently talking about this, I am wg> sure this feature will make it into one of the upcoming releases. Al wg> always, 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>
