Well, there's BaseFactory and all its sub-types that seems like a natural fit, doesn't it ?
Werner On Wed, 4 May 2005 09:21:24 -0400, Matt Harvey wrote: >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> >
