Well you have to ask if you want to use a CMS API, (or even a CMS) versus roll-your-own using a DB directly.
A CMS and JCR provide a lot of value which you may not appreciate until you try to replicate some of the features in a DBMS based system. I am only new to JCR myself, but mostly I am finding that the "quirks" that are there make me use it in a way that is optimal for managing *content* - ie people who know more about content then me. I like that "opinionated" approach, as I don't know enough about CMS to build an API myself, so am happy to be shown the way by JCR. On 10/2/06, behrangsa <[EMAIL PROTECTED]> wrote:
Doug, Thanks for the reply. Does it imply that using JCR has a __serious__ performance penalty compared to direct access to the database via JDBC, and even using ORM tools such as EJB3? BTW - There's a good comparison of JCR to File Systems and DBs available at http://www.day.com/site/en/index/products/content-centric_infrastructure/content_repository/crx_faq.html But I am still confused as to when one should consider using JCR* as a fundamental component of an enterprise project? For what kind of projects does it make sense to use JCR? Once we consider using JCR, should we store/retrieve everything via JCR? Or only a portion of the project should be so? *JCR or any other CMS (?) API Regards, Behi Doug Douglass-2 wrote: > > Behi, > > I think the only thing you're missing is locking. Many (most) RDBMS have > some level of built-in/implicit locking of the table or, better yet the > row, > for write operations. This is not true of JCR, you must explicitly > lock/unlock your nodes to prevent concurrent update attempts. > > HTH, > Doug > > On 10/1/06, behrangsa <[EMAIL PROTECTED]> wrote: >> >> >> Hi, >> >> The concurrent update capability of JCR is a little bit confusing to me. >> >> In an RDBMS, when I execute the following code sinppet simultaneously by >> a >> few threads, no problem rises: >> >> tx.being(); >> executeUpdate("insert into positions(id, name, parentId) values (?, ?, >> 1)"); >> tx.commit(); >> >> In JCR, the equivalent to this seems to be: >> >> tx.begin(); >> Node positions = session.getRootNode().getNode("positions"); >> Node pos = positions.addNode("position"); >> pos.setProperty("name", "some name"); >> tx.commit(); >> >> But apparantly this throws an InvalidItemStateException (am I right?) >> when >> multiple sessions concurrently execute this snippet of code. If this is >> true, then how can one handle the aforementioned SQL operation in JCR? >> >> Regards, >> Behi (via Nabble :-) >> -- >> View this message in context: >> http://www.nabble.com/Comparing-an-RDBMS-to-JCR-tf2366850.html#a6593713 >> Sent from the Jackrabbit - Users mailing list archive at Nabble.com. >> >> > > -- View this message in context: http://www.nabble.com/Comparing-an-RDBMS-to-JCR-tf2366850.html#a6594059 Sent from the Jackrabbit - Users mailing list archive at Nabble.com.
