You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jackrabbit.apache.org by David Nuescheler <da...@gmail.com> on 2004/11/01 11:26:16 UTC
Re: Jackrabbit Transactions [former: Adding WebDAV to Jackrabbit]
hi oli,
just one more thing, now that i was looking at the slide transactions:
why did you guys implement your own org.apache.slide.transaction.SlideXid, and
all the other stuff that in my mind belongs into the transaction manager?
http://jakarta.apache.org/slide/javadoc/org/apache/slide/transaction/SlideXid.html
did you guys implement your own transaction monitor?
[experiencing my confusion when looking at the slide tx, i can
understand your confusion looking at the jackrabbit tx. LOL]
regards,
david
Re: Jackrabbit Transactions [former: Adding WebDAV to Jackrabbit]
Posted by Oliver Zeigermann <ol...@gmail.com>.
On Mon, 1 Nov 2004 15:01:50 +0100, David Nuescheler
<da...@gmail.com> wrote:
> > 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...
> to me, the way how the repository chooses to interact
> with its stores, does not have to be exposed to the
> repository user (developer). i understand that for
It is not.
> people that develop stores this is very interesting.
> however i think for the vast majority of content
> repository application developer should not develop
> stores, much like the j2ee devs should not develop
> for example jms provider components.
They do not need to.
> again, thank you very much for the
> interesting discussions, i think this certainly
> helps me to learn a lot about slide.
Thanks as well!
Oliver
Re: Jackrabbit Transactions [former: Adding WebDAV to Jackrabbit]
Posted by David Nuescheler <da...@gmail.com>.
> 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.
hmmm... while i appreciate a feature of virtualizing multiple
datasources in a single tree,
http://www.day.com/content/en/product/productline/contentbus.html
i would still question an architecture where a repository has
to ship its own tm. if the slide tm is a good general purpose
tm, then i would suggest that you talk to the geronimo
guys since they probably should be interested, or am i
way off here?
> 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.
a comparison that involves proprietary and standardized apis, a
protocol and a querylanguage makes my head spin ;)
> 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.
i think to use webdav as a protocol to remote
a "content repository api" is a very good idea, that we already
discussed with remy (& others) about 2 years ago.
[ also see a couple of post earlier on this list ]
i think we additionally benefit from the fact that we do not
remote a proprietary api but one that is specified through a jsr,
which means that the application developer is not just
independant from the server implementation but
also from the transport protocol between the client and
the server (just like with jdbc, to put that in the correct perspective).
or to unspin my head, we can maybe agree to to something like that:
jdbc is for rdbms, what jcr is for content repositories.
> 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...
to me, the way how the repository chooses to interact
with its stores, does not have to be exposed to the
repository user (developer). i understand that for
people that develop stores this is very interesting.
however i think for the vast majority of content
repository application developer should not develop
stores, much like the j2ee devs should not develop
for example jms provider components.
again, thank you very much for the
interesting discussions, i think this certainly
helps me to learn a lot about slide.
regards,
david
Re: Jackrabbit Transactions [former: Adding WebDAV to Jackrabbit]
Posted by Oliver Zeigermann <ol...@gmail.com>.
On Mon, 1 Nov 2004 12:10:14 +0100, David Nuescheler
<da...@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
Re: Jackrabbit Transactions [former: Adding WebDAV to Jackrabbit]
Posted by David Nuescheler <da...@gmail.com>.
> Actually Slide has its own JTA implementation!
ouch ;)
> 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?
> 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.
> 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?"
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.
regards,
david
Re: Jackrabbit Transactions [former: Adding WebDAV to Jackrabbit]
Posted by Oliver Zeigermann <ol...@gmail.com>.
Yes, anyone lives in his/her own world. Me as well :)
Actually Slide has its own JTA implementation! 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. 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.
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.
Oliver
On Mon, 1 Nov 2004 11:26:16 +0100, David Nuescheler
<da...@gmail.com> wrote:
> hi oli,
>
> just one more thing, now that i was looking at the slide transactions:
> why did you guys implement your own org.apache.slide.transaction.SlideXid, and
> all the other stuff that in my mind belongs into the transaction manager?
> http://jakarta.apache.org/slide/javadoc/org/apache/slide/transaction/SlideXid.html
>
> did you guys implement your own transaction monitor?
>
> [experiencing my confusion when looking at the slide tx, i can
> understand your confusion looking at the jackrabbit tx. LOL]
>
> regards,
> david
>