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.
Noted.
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? :-)
Vadim
