hi dirk,
According to the Webdav Access Control specs HTTP resources that support
Webdav Access control protocol
must have a owner property that identifies a particular principal as the
owner of the resource.But i do not see the
owner property being stored anywhere.Also when i look at the
implementation of the propfind method on the server side i see that a
request for all the property names returns "owner" as one of the properties
but a request for value of the owner property on a resource returns "Not
Found" . Also according to the spec a principal MUST report the
DAV:principal empty XML element in the value of the DAV:resourcetype
property in addition to all other reported elements.But i did not see this
happening. Can you please clarify these issues for me.
thanks,
rajkumar
-----Original Message-----
From: Dirk Verbeeck [mailto:[EMAIL PROTECTED]]
Sent: Thursday, September 20, 2001 11:03 AM
To: Slide Developers List
Cc: Jacob Lund; Raj Kumar
Subject: Cloudscape & transactions
I have been looking at the problems Jacob had with cloudscape and it
looks like another setAutoCommit problem (like the one Raj is having).
Some background (see 212 & 473)
http://www.cloudscape.com/support/faq.jsp?module=4&showall=yes
"Some products have held cursors, which permits cursors to stay open
past commits; however, Cloudscape does not have that functionality.
Committing a
transaction closes all open ResultSet objects and currently executing
statements. You also need to be careful to process all results sets
prior to issuing a commit in
your code."
When executing read-only methods outside start/commit the
connection.autocommit is set to true.
This gives the problems with cloudscape when using
"retrieveRevisionDescriptors".
In that method there is a select statement that is closed inside a loop
over another resultset, when the inner statement is closed, an
autocommit occurs and the outher statement is closed with as result, a
SQLException.
There are 2 solutions for this problem.
1) Untangle the 2 loops. Put the results of the first in a vector and
use the vector to loop.
2) always have autocommit=false. We set this in connect and remove the
setAutoCommits from start,commit and rollback.
I would also do a connection.rollback in the start method.
Personally, I would go with option 2 but this changes the behaviour when
you are not inside a (slide)transaction.
Now all changes are silently committed, with option 2 all changes
outside a (slide)transaction are discarded.
Remarks?
Dirk
