jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Padraic I. Hannon" <...@wasabicowboy.com>
Subject Re: [jira] Created: (JCR-1050) Remove synchronization from JNDI data sources
Date Fri, 17 Aug 2007 04:40:54 GMT
I think at the core I am thinking that the persistence manager need not 
be a single threaded mechanism for accessing the database. If a 
connection manager is a singleton I can see the argument for thread 
safety, however, I do not see why these would have to be singletons, 
I'll look more into how sessions talk to the persistence manager, I 
think that the scope of the suggested change just got larger as there 
should be a new manager per session, ie per usage thread.

-paddy

Thomas Mueller wrote:
> 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
>   


Mime
View raw message