jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vadim Gritsenko <va...@reverycodes.com>
Subject Re: Is JDBC persistence manager supported by jackrabbit?
Date Fri, 02 Sep 2005 15:10:13 GMT
Marcel Reutegger wrote:
> Vadim Gritsenko wrote:
>> Marcel Reutegger wrote:
>>> Feel free to provide patches to enhance concurrency.
>> My first patch than will be port of connection pools from Edgar's JDBC 
>> PM. Once DB PM has access to DB connection pool, there will be no need 
>> for any synchronizations. Would you accept it?
> hmm, I might be wrong, but I don't think Edgar has implemented a DB 
> connection pool. Or are you refering to some pooling implementation in OJB?

He implemented connection factory and several implementations, providing ways to 
configure new/use existing connection pool.

> When submitting a patch please try to keep the newly introduced 
> dependencies to a minimum. We also prefer implementations that work with 
> a minimum of configuration overhead.


>>> Some enhancements that crossed my mind are:
>>> - use a separate read-only connection for load() and exists() operations
>>> - use a pool of prepared statements for load() and exists()
>> There are issues with single/double-connection design, beside the fact 
>> that (j2ee) applications are discouraged from managing system 
>> resources themselves:
> Jackrabbit is not an j2ee application, but rather a resource itself.


Dunno about you but I envision that jackrabbit in 90% of situations will be used 
from within webapp (hence will have jndi, connection pool, and sometimes xa tx), 
1% in desktop apps ;-), and the rest are 'big iron' non-clustered deployments - 
the only way to scale it will be using bigger hardware, right? :-)

> Jackrabbit also runs without an application server and should therefore 
> not require j2ee infrastructure (though it may use it if available). 
> Which makes it a question of internal design how jackrabbit handles 
> resources.

Of course, and it should stay that way too. But if j2ee is present it should 
take advantage of that, right? :-)


View raw message