jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Chandresh Turakhia" <chand.turak...@bhartitelesoft.com>
Subject Re: DP Persistence manager implementation
Date Thu, 02 Feb 2006 11:47:22 GMT
Team ,

Both Oracle and DB have give FREE version of database. Can we start giving 
DB PersistanceManager for Oracle / DB2 inbuilt in Jackrabbit since it can be 

I do agree it would be appropriate Nice to look at Jakarta commons dbcp.

Quick Question 1) Oracle and DB2 commes with multimedia features. Since many 
a time , most CMS have multimedia content , Can we extent the 
OraclePersistanceManager to include the same. Can any one suggest how to use 
most of Oracle intermedia features using repository architecture ? I would 
want to do the same for my project.

Quick Question 2 ) Most CMS want to store Metadata as RDF. Oracle support 
RDF storage. Can repository be extended for the same.

Thanks in advance.



DB2 Express-C is completely "free" to download, develop, deploy, test, run, 
embed, and redistribute. For more information click here
  a.. Maximum processors: 2
  b.. Maximum addressable memory: 4GB
Oracle Database 10g Express Edition (Oracle Database XE) is an entry-level, 
small-footprint database based on the Oracle Database 10g Release 2 code 
base that's free to develop, deploy, and distribute; fast to download; and 
simple to administer. Oracle Database XE is a great starter database for:

  a.. Developers working on PHP, Java, .NET, and Open Source applications
With Oracle Database XE, currently available as a Beta release for Windows 
and Linux, you can now develop and deploy applications with a powerful, 
proven, industry-leading infrastructure, and then upgrade when necessary 
without costly and complex migrations. A production release is scheduled for 
early 2006.

Oracle Database XE can be installed on any size host machine with any number 
of CPUs, but this free version of the world's leading database will store up 
to 4GB of user data, use up to 1GB of memory, and use one CPU on the host 


----- Original Message ----- 
From: "Miro Walker" <miro.walker@cognifide.com>
To: <jackrabbit-dev@incubator.apache.org>
Sent: Thursday, February 02, 2006 2:38 AM
Subject: DP Persistence manager implementation

> Hi,
> We've been discussing the DB PM implementation, and have a couple of
> questions regarding the implementation of this. At the moment, the
> Simple DB PM appears to have been implemented using a single connection
> with all write operations synchronised on a single object. This would
> imply that all writes to the database are single threaded, effectively
> making any application using it also run single threaded for write
> operations. This appears to have two implications:
> 1. Performance - in a multi-user system, having single-threaded writes
> to the database will make the JDBC connection a serious bottleneck as
> soon as the application comes under load. It also means that any
> background processing that needs to iterate over the repository making
> changes (and we have a few of those) will effectively bring all other
> users to a grinding halt.
> 2. Transactions - we haven't tested this (as the recent support for
> transactions in versioning operations has not been integrated into our
> system), but it appears that to if a single connection is being used,
> then we can only have a single transaction active at any one time. So,
> if each user tries to execute a transaction with multiple write
> operations in it, and these transactions are to be propagated through to
> the database, then each transaction must complete before the next can
> begin. This would either mean we get exceptions if the system attempts
> to interleave operations from different transactions or that each
> transaction must complete in full before another can begin, further
> compounding the performance issue.
> In addition to the implications of using a single synchronised
> connection, another issue appears to be that the system will be unable
> to recover from a connection failure. For example, if the system were
> deployed onto a highly available database cluster, then in the event of
> DB instance failure, any open connections will be killed, but can quite
> happily be reopened later. Jackrabbit appears to create a connection on
> initialisation, and has no way to recover if that connection is killed.
> I know that questions around implementing support for connection pooling
> on the DB have been raised before and then dismissed as unimportant, but
> this appears to me to be pretty fundamental. By using a connection pool
> implementation that supports recreating dead connections and supports
> providing tying a connection to a transaction context, multiple
> transactions could run in parallel, helping throughput and making the
> system more reliable.
> What do people think? Could we look to use Jakarta commons dbcp?
> Cheers,
> Miro

View raw message