On Mon, 1 Nov 2004 12:10:14 +0100, David Nuescheler
<david.nuescheler@gmail.com> wrote:
> > I do not know
> > what historical even was causing this, but it at least has the
> > benefit that you do not need a full J2EE server. The drawback
> > was/is that it is pretty hard to let Slide participate in a distributed
> > transaction of a J2EE server.
> hmmm.... i see... but wouldn't it be pointless to implement
> xa, if you cannot participate in a distributed transaction?
> to me that is the idea of xa, global transactions?
That's Slide's special feature. You can map all kinds of stores to
resource paths. You can even do this with different aspects of a
resource. E.g. you can store all content of resources in a folder to
the file system and all the meta data into an RDBMS. All other paths
could well be mapped to be help in memory only (just as an example).
Now it should be obvious that all stores need to participate in the
global tx as a resource might affect all stores. They do so by
implemention XAResource.
> > As the server side Slide API is suboptimal (hihi)
> > to program to and it is hard to change the transaction
> > manager the solution was to create a client side JCA
> > connector talking WebDAV to Slide that can participate
> > in a JTA transaction of your J2EE server.
> > This way you have a simply API (client side) to program
> > to as well.
> hmm... i would argue that it certainly makes a lot of sense
> to have a repository implement jca, which certainly are
> the plans ( model 2 on http://incubator.apache.org/jackrabbit/arch/deploy.html )
> this would then also expose a LocalTransaction, which in
> my mind is effectively what you get from implementing
> your proprietary (local) tm.
> i do not entirely see why webdav needs to be in the picture
> for that.
WebDAV and the client library and WebDAV JCA implementation for Slide
is like JDBC and SQL for RDBMS.
Using the client Side JCA implementation you can have both a local and
a distributed transaction.
As a side note if anyone asks I always recommend not to use Slide's
native API, but to go the "SQL and JDBC" way. This even makes your
implementaion independent of Slide and you could *theoretically* -
just like with SQL and JDBC ;) - exchange Slide with another WebDAV
server - like SVN for example - which people seem to experiment with
already.
> > Having said that, maybe it gets a bit easier to understand
> > where I am coming from. Maybe it even is easier to explain
> > what are the differences in Jackrabbit.
> i think that clears up things for me... my question would
> only be,
> "why would you ever do that?"
> ... and if you for whatever reason decide to
> implement a tm ...
> "why wouldn't you do it really according to the jta spec,
> where XAResources are enlisted with the xa tx?"
As explained above this is the way it works. Each store implements
XAResources and is enlisted in the global transaction.
> to me the slide transactions look like they are not really
> jta, but just somehow use some jta interfaces in a
> questionable way. but again my apologies, i might be
> completely wrong here.
No need for apologies, but it seems to me you are wrong here...
Oliver