[
https://issues.apache.org/jira/browse/JCR-1050?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12520259
]
Stefan Guggisberg commented on JCR-1050:
----------------------------------------
discussion on the dev list:
---------- Forwarded message ----------
From: Thomas Mueller <[EMAIL PROTECTED]>
Date: Aug 10, 2007 8:56 AM
Subject: Re: [jira] Created: (JCR-1050) Remove synchronization from JNDI data
sources
To: dev@jackrabbit.apache.org
Hi,
> I am not suggesting this be the only driver, just that the JNDI drive should
> be built in such a way as to make use of the facilities provided by JEE
> containers (datasources, jta, etc).
I think using JNDI as an alternative way to get the connection is fine.
> > Do you suggest to create a new PreparedStatement for each request?
> > <response>
> > Yes, let the datasource or DB handle caching the PreparedStatements rather
> > than holding them in an internal map.
> > </response>
I don't think there are advantages in using prepared statements from a
data source compared to using your own prepared statements.
> pre-creating ... should not be needed.
I agree, it's not required to create all prepared statements when
connecting. It would be OK if they are created when required (and then
put in a hash map or so).
> holding onto the connection for long periods ... should not be needed.
Except for MySQL (where the connection drops after a few hours) I
don't see a problem doing that. There is a risk (for all remote
databases) that the connection drops temporarily (network cable
disconnected or so), but if you want to solve that you need to add
some reconnect functionality - even when using data sources.
> > advantages of 'not holding onto the connection'?
> Why hold onto resources one is not using?
> Let other threads take them.
You mean other threads inside Jackrabbit? As far as I know, the
persistence engine of Jackrabbit doesn't require multiple connections.
Or do you mean other threads inside other applications? I suggest not
to access Jackrabbit databases directly.
> Less code in jackrabbit for managing transactions
I don't think it would be less code. You anyway need to maintain the
current behavior (using DriverManager to get the connection). So
adding separate persistence managers (would be required for all
databases) would double the maintenance work? I think there are
already too many persistence managers.
But I agree, getting the connection from a data source would make
sense. This could be integrated into the current persistence
manager(s).
> and less synchronization leading to less potential threading conflicts.
You probably mean higher concurrency. However I don't think that this
would be possible just because data sources are used.
> synchronization has serious performance penalties in high traffic situations.
> In general I would think that the fewer synchronized parts the better.
When using one connection: Some JDBC drivers are not thread-safe, that
means there is a risk accessing the same connection using multiple
threads at the same time. Others are thread-safe, but synchronize
internally, so there would be no benefit.
When using multiple connections, there are new problems. Are you
suggesting to use multiple connections inside one persistence manager?
The connection defines the scope of the transaction, so using multiple
connections would mean multiple concurrent transactions. As far as I
know, the current Jackrabbit engine does not support this. Actually, I
think Jackrabbit _should_ use one database connection per session. The
problem is, the architecture is currently no like that.
> the purpose of synchronized blocks was to handle the fact that statements and
> connections where held open for long periods by the driver.
I don't think this is the reason why synchronization is used (but I
might be wrong). In my view, synchronization is used to make sure the
JDBC objects (statements, result sets) are not accessed concurrently.
> that allowing multiple threads to read would have
> serious performance implications
With the current architecture, I don't think removing synchronization
would improve the performance. But if it does improve performance, or
course this should be implemented.
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.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
