cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rolf Kulemann <>
Subject Re: [New Repository] Major design issue concerning state
Date Fri, 09 Apr 2004 07:39:08 GMT
On Fri, 2004-04-09 at 09:22, Rolf Kulemann wrote:
> On Fri, 2004-04-09 at 08:34, Rolf Kulemann wrote:
> > Hello,
> > 
> > I see I'm lucky "moving that quick", because otherwise I never would
> > have found out the following.
> > 
> > I did a small sample with the WebDAVRepository. I'm creating docs, read
> > and write properties and version the docs via the WebDAV impl. of the
> > "new repository". Lets have a look at the requirement to create a newly
> > and LOCKED file in the repository. Using i.e. slides commandline client
> > for WebDAV u simple execute a) "lock newfilename.xml" and b) "put
> > src.xml newfilename.xml". BUT this only works within the same session.
> > 
> > That means if I lock into the webdav server a second time with the same
> > user, b) is not possible, because the lock is not only associated with
> > the user, but also bound to special session, here the first session.
> > 
> > To avoid this, the repsoitory impls. MUST act on the same WebdavResource
> > during a user session, but this is not possible by design!
> > 
> > Why?: Normally the Sources i.e. c) WebDAVSource are wrapping a special
> > d) WebdavResource. c) acts in all requests on the same d) which maintain
> > the state.
> > 
> > I have thought about alternatives, but all lead to concept where we
> > "need to pass around sth." reflecting the state. And that sth. is a
> > Source imho.
> Ok, I found maybe a solution for my special problem to create locked
> resources in order to avoid races. I try to forget now, that there maybe
> more state issues.
> So it could be useful to add the following methods to the Repository
> inteface or to the RepositoryVersioningHelper.
> - createResource(String url, String content, boolean locked)
> I think this would solve my major issue, because during the call, the
> rep. impl can act for both operations (lock and put) on the same
> WebdavResource. Of course this could be different implemented for other
> repositories than WebDAV, but WebDAV behaves that way.

BUT another major problem is:

What if u want to lock a collection in order that lets say nobody than
me can add nodes to it. Normally I would lock the collection and then
invoke the createResource(), BUT this will not work, since the lock was
created in a different session. 

How can this be "workarounded"??

createResource(String lockurl, String relativePath, String content)


    Rolf Kulemann

View raw message