[Cosmo-dev] prototyping cosmo with jdbc instead of jcr

[rletness at simdeskcorp.com]

I think this is a great idea.  Have you taken a look at the Bedework project (www.bedework.org)?  They use hibernate to store calendar and event data and have a caldav layer on top of that.

-Randy



Brian Moseley wrote:

> a few threads over recent weeks have approached the subject of
> jackrabbit's scalability and operational challenges. most agree that
> jcr has a lot of promise and seems to be a good fit with a
> webdav-oriented hierarchical data store, but it's clear that
> jackrabbit has a long way to go before it can efficiently scale to the
> numbers of users, calendars and events we're targeting with cosmo.
>
> i propose to build a prototype of cosmo that stores its data directly
> into a relational database using hibernate to map the cosmo domain
> model to the relational schema. see <http://hibernate.org/> for more
> info on hibernate.
>
> the advantages to such an architecture are many. with more control
> over how our data is stored, we can optimize for our most troublesome
> use cases (PROPFIND against a thousand event calendar, for example).
> by replacing the state-heavy but non-clusterable, mainly non-remotable
> jackrabbit with a more traditional j2ee style webapp talking to an
> rdbms, we achieve horizontal scalability with both server tiers. we
> can take advantage of mature, professional quality management tools
> for the app server and db server. and we don't have a "black box"
> component that few people understand, which reduces the number of head
> scratching bugs or performance problems that typically require a large
> dose of experience with the software to resolve.
>
> i do see a couple disadvantages as well. cosmo is currently stateless,
> which is the holy grail for the app server tier, but we may need to
> introduce some user state in order to effectively cope with situations
> like concurrent writes to the same calendar. it's unclear whether or
> not this will be needed, but even if it is, app server clustering (and
> cache clustering) is not only possible but is a well known technology
> area with lots of mature solutions. another potential disadvantage is
> that we'll eventually have to implement resource locking, which we get
> for free with jcr, but i don't think that's a particularly difficult
> problem to solve.
>
> a side benefit of this prototype would be a refactoring of the
> jcr-server library that we use to implement the server side webdav
> protocol handling. this would be required in order to replace the
> current jcr implementation of webdav and caldav with the hibernate
> implementation. the refactoring will make the protocol layer code a
> lot easier to understand and explain, and even more importantly, it
> will become unit testable (unit level testing is impossible today).
>
> my plan is to have something functional within the next couple of
> weeks that we can use to make further decisions on our architectural
> direction. i'm also going to continue exploring the problem areas of
> our current jackrabbit usage, in case there are more tweaks or tuning
> knobs that we haven't found yet.
>
> thoughts on this proposal? concerns? think i'm nuts?
> _______________________________________________
> cosmo-dev mailing list
> cosmo-dev at lists.osafoundation.org
> http://lists.osafoundation.org/mailman/listinfo/cosmo-dev
>