Stefan Guggisberg (JIRA) wrote: > [ > https://issues.apache.org/jira/browse/JCR-1050?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12520257 > ] > > Stefan Guggisberg commented on JCR-1050: > ---------------------------------------- > > discussion on the dev list: > > ---------- Forwarded message ---------- > From: Thomas Mueller <[EMAIL PROTECTED]> > Date: Aug 2, 2007 9:33 AM > Subject: Re: [jira] Created: (JCR-1050) Remove synchronization from JNDI data > sources > To: dev@jackrabbit.apache.org > > > Hi, > > I'm not sure if I understand this request for improvement. > > >> Using datasources >> > > So you suggest to use DataSource.getConnection(..) instead of > DriverManager.getConnection(..)? How do you get / create the > datasource object, using JNDI? What about embedded applications where > JNDI is not available? > I really would like to see Jackrabbit to support DataSource and JNDI.
This simplifies the usage in an application server and corporate environments (corporate = the AS admins configure the datasource in the AS and will ask questions why you got a JEE app which can not use the Jdbc Pool for connections ... no chance that in your role as a 'application provider' you will the the production DB password!). How about - Use commons-dbcp for creating and managing datasource - All DB backed PM/FS only use an 'injected' DataSource to get a single connection for now. This greatly reduces the redundant create-connection-from-driver-manager logic from FS, PM and for all implementation types (bundled, simple, ...). Reconnects fetch a fresh connection from the data source. - Create a JNDI PM/FS wrapper for datasource based PM/FS which would fetch the data source from JNDI and inject it into the wrapped PM/FS. >> one should be able to rely on the application server to manage >> PreparedStatement caches >> > > Do you suggest to create a new PreparedStatement for each request? > > As already mentioned before in this thread: a JEE datasource pool handles PrepStat caching nicely (nice article: http://www.theserverside.com/tt/articles/article.tss?l=Prepared-Statments) I'm not sure if commons-dbcp would do that, too ... ??? >> therefore pre-creating and holding onto the connection for long periods of >> time should not be needed. >> > > Could you explain the advantages of 'not holding onto the connection'? > I know that MySQL closes connections after 8 hours idle time, are > there any other advantages? > > The mysql idle timeout can be configured on the server side. Also, some firewalls close idle connections. Connection pools can 'health' check the connections before handing one to the application (eg JR). Most DB vendors provide optimized health checking utils (eg for mysql when configuring a datasource on JBoss). >> This relates to improvement JCR-313, however, that change did not address >> the benefits one could see in using an application server controlled >> datasource. >> > > What are those benefits? > > >> Even if jackrabbit does aim to use an embedded database such a system could >> be configured to use datasources and >> > > >> could benefit from the removal of the synchronization. >> > > In what way would removal of the synchronization be a benefit? Do you > think it would be faster without synchronization? How would you make > sure statements are executed in the right order? > > Thanks, > Thomas > > >> Remove synchronization from JNDI data sources >> --------------------------------------------- >> >> Key: JCR-1050 >> URL: https://issues.apache.org/jira/browse/JCR-1050 >> Project: Jackrabbit >> Issue Type: Improvement >> Components: core >> Reporter: Padraic Hannon >> Attachments: JNDI_Datasource_Changes.diff >> >> >> Using datasources one should be able to rely on the application server to >> manage PreparedStatement caches therefore pre-creating and holding onto the >> connection for long periods of time should not be needed. This relates to >> improvement JCR-313, however, that change did not address the benefits one >> could see in using an application server controlled datasource. Even if >> jackrabbit does aim to use an embedded database such a system could be >> configured to use datasources and could benefit from the removal of the >> synchronization. >> > >
