On 9/5/07, Paul Brown <[EMAIL PROTECTED]> wrote: > > Let me try to put a finer point on what Maciej's saying. Part of the > infrastructure that the engine maintains is the set of correlation > keys, and there is some magic to do pre-computation of keys for > processes. This facility puts a lot of traffic in that table in the > database, so it's not so much transactions as having fine-grained > locking available. > > That said, it's reasonable (and maybe desirable for other purposes) to > think about splitting the DAO implementation into a couple of > components -- one part in a traditional data store of some flavor for > the correlations and a few other things and then one part in a storage > medium like the JCR, an XML database, etc.
I think we should start by turning the question around. What are the use cases we want to support? When it comes to data used by the process, I think there's a reasonable justification to make it accessible to as many applications as possible, with the possibility of having that data reside in data stores that are provided separately from the process engine. When it comes to data used by the process engine internally, I don't see any compelling argument to decouple it from the process engine, and if the process engine is best written in term of JDBC calls with certain RDBMS assumptions, so be it. Assaf Just a thought. > > -- Paul > > > On 9/5/07, Philipp Koch <[EMAIL PROTECTED]> wrote: > > > i'm guessing it might not practical to > > > get that working using a content repository, since it is very > > > "transactional" and prone to dead-lock. > > you are talking about ode by saying " is very "transactional""? well > > the jsr170 spec also supports for transactions, so does the jackrabbit > > implementation (as reference impl)! i already did some migrations from > > apps formerly using a db to jcr. it worked perfect! > > > > regards, philipp > > > > On 9/5/07, Maciej Szefler <[EMAIL PROTECTED]> wrote: > > > so the hand-coding of jdbc i mentioned involves the code used to route > > > messages to the appropriate instance. i'm guessing it might not > practical to > > > get that working using a content repository, since it is very > > > "transactional" and prone to dead-lock. > > > > > > -mbs > > > > > > On 9/5/07, harvey waters <[EMAIL PROTECTED]> wrote: > > > > > > > > I was thinking of that as well. The main issue I guess would be to > get > > > > ode's > > > > unit tests running against a new dao layer. Does anyone know if this > is > > > > achievable ? > > > > > > > > On 9/5/07, Philipp Koch <[EMAIL PROTECTED]> wrote: > > > > > > > > > > hi, > > > > > there is a ocm (object content mapping) (sub) project in the > > > > > jackrabbit contrib folder > > > > > ( > > > > > > > > > > http://svn.apache.org/repos/asf/jackrabbit/trunk/contrib/jackrabbit-jcr-mapping/ > > > > > ) > > > > > which might be from interesst. > > > > > > > > > > regards, philipp > > > > > > > > > > On 9/4/07, harvey waters <[EMAIL PROTECTED]> wrote: > > > > > > Well I know the JSR170 but not the ode. What do you mean by the > > > > message > > > > > > correlation code would need to be hand coded, do you just mean a > piece > > > > > of > > > > > > code that would be specifically hand coded for the JSR170 DAO's. > > > > > > > > > > > > On 9/4/07, Maciej Szefler <[EMAIL PROTECTED]> wrote: > > > > > > > > > > > > > > don't know much about JCR, but yes, in theory you'd need to > > > > > reimplement > > > > > > > the > > > > > > > DAO in the JCR170 "medium". A warning though, there are things > that > > > > > you > > > > > > > would almost certainly create problems, in particular the > message > > > > > > > correlation code really needs to be hand-coded in something > like > > > > JDBC > > > > > to > > > > > > > work correctly. > > > > > > > > > > > > > > -mbs > > > > > > > > > > > > > > On 9/4/07, harvey waters <[EMAIL PROTECTED]> wrote: > > > > > > > > > > > > > > > > Would the bean encoder be a better appoach than developing a > > > > jcrDAO > > > > > > > layer > > > > > > > > ? > > > > > > > > are you thinking that the bean encoder would allow you to > use > > > > other > > > > > > > > repositories than the jsr170 ? > > > > > > > > > > > > > > > > On 9/4/07, Nicolas Modrzyk <[EMAIL PROTECTED]> > wrote: > > > > > > > > > > > > > > > > > > Hey Harvey, > > > > > > > > > > > > > > > > > > Storing a workflow has been done in the magnolia CMS. > > > > > > > > > > > > > > > > > > You may be interested in looking at: > > > > > > > > > http://www.openwfe.org/openwfe-jcr-beancoder.html > > > > > > > > > > > > > > > > > > It should be quite easy to plug it or something similar to > ODE. > > > > > > > > > > > > > > > > > > Niko, > > > > > > > > > > > > > > > > > > > > > > > > > > > On Sep 4, 2007, at 6:00 PM, harvey waters wrote: > > > > > > > > > > > > > > > > > > > I would like to use ode with a jsr170 persistance layer > > > > (Apache > > > > > > > > > > JackRabbit), > > > > > > > > > > basically I want to be able to be able to persist the > workflow > > > > > (and > > > > > > > > > > its > > > > > > > > > > state) in the content repository. Am I right in thinking > that > > > > I > > > > > > > > > > would need > > > > > > > > > > to develop a jsr170 dao layer. Is this feasable and is > there > > > > > > > > > > someone out > > > > > > > > > > there who is already doing it ? > > > > > > > > > > > > > > > > > > > > Thanks > > > > > > > > > > > > > > > > > > > > Harvey > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > [EMAIL PROTECTED] > http://mult.ifario.us/ >
