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
packed.
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.
Chand
FYI
http://www-306.ibm.com/software/data/db2/udb/edition-expressc.html
DB2 Express-C is completely "free" to download, develop, deploy, test, run,
embed, and redistribute. For more information click here
Restrictions:
a.. Maximum processors: 2
b.. Maximum addressable memory: 4GB
ww.oracle.com/technology/products/database/xe/index.html
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.
Restrictions:
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
machine.
Regards
Chand
----- Original Message -----
From: "Miro Walker" <[EMAIL PROTECTED]>
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
