cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephan Michels <step...@apache.org>
Subject Re: [RT] Future of the Slide Source
Date Wed, 14 Apr 2004 08:44:47 GMT
Am Mi, den 14.04.2004 schrieb Mats Norén um 10:08:
> Hi,
> I've been following the discussions on both the repository API and the 
> Slide Source and I have a few questions to consider.
> The Source IF is an abstraction layer but not a particularly good one in 
> this context.
> I agree that the Slide Source should be dropped but I don´t agree that 
> another source is the complete solution.
> A source in this context is (in my POV)  a data object and you need ways 
> to manipulate data objects in the scope of a transaction, this is not 
> possible with a Source as it stands to day.
> I´ve been a part of  a project that built a CMS on top of Cocoon (flow), 
> Slide and the *unstable* Slide Source.
> The biggest problem with the Source abstraction is the manipulation of 
> properties and content and the lack of transactions spanning over 
> several source actions when doing these manipulations.
> Sources were designed for reading information and not for manipulating them.
> Naturally one could build something on top of a Source abstraction that 
> encapsulated Source operations within a transaction but what´s the point 
> in that when you could have a repository IF working directly with Slide 
> which supports transactions?
> I guess what I'm trying to say is that a WebDAV Source +  a Repository 
> IF that doesn´t overlap is what I would have liked if I were to build 
> yet another CMS on top of Cocoon and WebDAV. :)

Thank you for your input. And yes transactions are a problem, especially
for webdav. I don't know the status of the transactions handling within
the webdav client. But I think the transaction handling must be
orthogonal to the interface, and not supported by it.

  UserTransaction tx = (UserTransaction) 
    new InitialContext().lookup("java:comp/UserTransaction"); 
  tx.begin(); 
  try { 
    ...//doing some soure or repository stuff 
    tx.commit(); 
  } catch (Exception e) { 
    tx.rollback(); 
  }

Through my memories reading the book "Concurrency (State models & java
programs)" the transactions can be implemented by using ThreadLocals.
So I think there is no need make the transactions explicit. Handling
transactions over the webdav protocol is a different capter, but I
thought that I read that Slide support it.

Stephan.


Mime
View raw message