Mailing-List: contact users-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@jackrabbit.apache.org
Received-SPF: pass (herse.apache.org: domain of brdavis@bea.com designates
 66.248.192.21 as permitted sender)
User-Agent: Microsoft-Entourage/11.3.3.061214
Date: Fri, 02 Mar 2007 12:06:16 -0800
Subject: Database PersistenceManagers (was "Results of a JR Oracle test
 that we conducted)
From: Bryan Davis <brdavis@bea.com>
To: <users@jackrabbit.apache.org>
Message-ID: <C20DC3B8.40C0%brdavis@bea.com>
Thread-Topic: Database PersistenceManagers (was "Results of a JR Oracle
 test that we conducted)
Thread-Index: AcddBjvuesGUUMj5EduydwAWy57LaA==
In-Reply-To: <49977f270703020340m72621bf8n2669ccb4fc9e8be@mail.gmail.com>
Mime-version: 1.0
Content-type: text/plain;
	charset="US-ASCII"
Content-transfer-encoding: 7bit

What persistence manager are you using?

Our tests indicate that the stock persistence managers are a significant
bottleneck for both writes and also initial reads to load the transient
store (on the order of .5 seconds per node when using a remote database like
MSSQL or Oracle).

The stock db persistence managers have all methods marked as "synchronized",
which blocks on the classdef (which means that even different persistence
managers for different workspaces will serialize all load, exists and store
operations).  Presumably this is because they allocate a JDBC connection at
startup and use it throughout, and the connection object is not
multithreaded.

This problem isn't as noticeable when you are using embedded Derby and
reading/writing to the file system, but when you are doing a network
operation to a database server, the network latency in combination with the
serialization of all database operations results in a significant
performance degradation.

The new bundle persistence manager (which isn't yet in SVN) improves things
dramatically since it inlines properties into the node, so loading or
persisting a node is only one operation (plus the additional connection for
the LOB) instead of one for the node and and one for each property.  The
bundle persistence manager also uses prepared statements and keeps a
PM-level cache of nodes (with properties) and also non-existent nodes (which
permits many exists() calls to return without accessing the database).

Changing all db persistence managers to use a datasource and get and release
connections inside of load, exists and store operations and eliminating the
method synchronization is a relatively simple change that further improves
performance for connecting to database servers.

There is a persistence manager with an ASL license called
"DataSourcePersistenceManager" which seems to the PM of choice for people
using Magnolia (which is backed by Jackrabbit).  It also uses prepared
statements and eliminates the current single-connection issues associated
with all of the stock db PMs.  It doesn't seem to have been submitted back
to the Jackrabbit project.  If you Google for
"com.iorgagroup.jackrabbit.core.state.db.DataSourcePersistenceManager" you
should be able to find it.

Finally, if you always use the Oracle 10g JDBC drivers, you do not need to
use the Oracle-specific PMs because the 10g drivers support the standard
BLOB API (in addition to the Oracle-specific BLOB API required by the older
9i drivers).  This is true even if you are connecting to an older database
server as the limitation was in the driver itself.  Frankly you should never
use the 9i drivers as they are pretty buggy and the 10g drivers represent a
complete rewrite.  Make sure you use the new driver package because the 10g
driver JAR also includes the older 9i drivers for backward-compatibility.
The new driver is in a new package (can't remember the exact name off the
top of my head).

Bryan.

_______________________________________________________________________
Notice:  This email message, together with any attachments, may contain
information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated
entities,  that may be confidential,  proprietary,  copyrighted  and/or
legally privileged, and is intended solely for the use of the individual
or entity named in this message. If you are not the intended recipient,
and have received this message in error, please immediately return this
by email and then delete it.