On 3/18/06, Jukka Zitting <[EMAIL PROTECTED]> wrote: > Hi, > > I just added JNDI/DataSource -based versions of the database > persistence manager and file system classes as requested in JCR-313. > The comments on the issue thread got me thinking about the current > "simple" approach and database configurability in general. The > database file system classes are pretty much mirrors of the > persistence manager counterparts, so I'll just focus on the PM classes > here, the same ideas apply to both situations. > > The JCR-313 issue thread focused much on the question of > implementation "simplicity". After going throught the code I think the > question has more to do with the approach of keeping the database > connection throughout the PM lifecycle and caching prepared statements > for performance rather than any inherent simplicity of the > implementaion approach.
'Simple' also refers to use of a very simple data model instead of a fully normalized schema or some object-relational mapping. > The main point seems to be that the current > implementation wants to prepare the used statements once during > initialization rather than once per method call. This is somewhat in > conflict with the J2EE best practice of keeping a database connection > and related resources like prepared statements only for the duration > of a single operation. those best practices apply to j2ee applications. the point is that i don't consider jackrabbit to be a j2ee application, jackrabbit is infrastructure and has other requirements regarding its persistence layer than a database application. > > Incidentally there happens to be one approach that would keep the > performance advantages of the current approach, remove the conflict > with J2EE practices, and even simplify the implementation! Like this: > > 1) Change the DatabasePersistenceManager to get a database connection > and prepare the used statements per each operation to comply with J2EE > practices. note that write operations must occur within a single transaction, i.e. you can't get a new connection for every write operation. > > 2) Use the Commons DBCP DriverAdapterCPDS DataSource implementation > with PreparedStatement pooling in SimpleDbPersistenceManager to keep > the performance gains. > > 3) Remove the now unneeded Connection and PreparedStatement members > and resetStatement() method from the DatabasePersistenceManager class > to simplify the implementation. > > The cost of this change would be a bit of pooling overhead per each > persistence manager operation (should be insignificang compared to the > cost of the database operations) and the introduction of commons-dbcp > and commons-pool as dependencies. > > This change would also clarify that the responsibility of any extra > database shutdown operations like in the current > DerbyPersistenceManager rests on the subclass as the > DatabasePersistenceManager class would no longer keep any stable > reference to the underlying database. > > What do you think? I can take a shot at implementing this if you think > it's worth doing. -1 for changing SimpleDbPersistenceManager as suggested right now on the other hand i have problem with adding a new more sophisticated db pm as suggested. time and experience will tell if we want to keep them both or not. cheers stefan > > BR, > > Jukka Zitting > > -- > Yukatan - http://yukatan.fi/ - [EMAIL PROTECTED] > Software craftsmanship, JCR consulting, and Java development >
