jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marcel May <marcel....@consol.de>
Subject Re: [jira] Commented: (JCR-1050) Remove synchronization from JNDI data sources
Date Thu, 16 Aug 2007 16:29:50 GMT
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 <thomas.tom.mueller@gmail.com>
> 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. 
>>     
>
>   



Mime
View raw message