Natalia Shilenkova wrote:
Hi all,
While working on Webadmin, I found that existing Xindice code may need
some modifications in order for WebDAV implementation to work more
efficiently.
1. According to WebDAV specification, methods such as PUT, COPY, or
MOVE must return different codes depending on previous existence of
the target resource. COPY and MOVE methods also have an option that
specifies if existing target resource can be overwritten. Because of
multithreading, to follow the specification most of the WebDAV methods
have to be synchronized, which is bad for performance. Alternatively,
class org.apache.xindice.core.Collection may provide some additional
functionality.
Though currently Collection has methods insert() and set(), they are
not really different and not enforced (looks like they were more
separated in the past). My suggestion is to change them so insert()
throws fault code if that key already exists in database and set()
inserts the resource if it is a new key or replaces existing resource.
It will help to resolve the problem with minimal changes in the
existing code.
Sounds good. In this case XML:DB Collection.storeResource() should be mapped to
the set(); it curently uses insert() in the embedded driver.
2. Creation and modification time for the resource can be accessed
from both filer record information and meta-data collection, but using
meta-data collection means client have to access two collections
instead of one for no reason.
Does the client needs only meta data, or both meta data and object data
(document/binary)?
If you want to retrieve meta data only -- like modification time -- retrieving
complete record, with data, would be less efficient than retrieving meta data only.
The only problem that Collection class
does not provide a way for its clients to get this information, when
Collection reads record from a filer, it discards everything except
record value.
Well, what if Collection's method getEntry() returns not just an
object, but some additional information it gets from the filer? Return
type would be an instance of a class that is similar to class Record,
but more high-level, so client can get basic resource properties
without making another round trip to database.
Yes this sounds good. There is creation/modification time on filer level which
is not exposed properly through collection.
I think I'd even prefer several variations of this method to cover different
usecases:
* Retrieve meta data only
* Retrieve object data only
* Retrieve both meta data and object data
First one would need two hits -- read filer record [Note 1] and read additional
meta data from meta data collection. Second requires only one hit to filer, and
third -- again two hits. WDYT?
Note 1: When retrieving filer meta data only, it would be nice to let filer know
that it should only read first page of the value, and should not read complete
value into the memory -- if all you need is creation/modification time, reading
complete value can be a significant performance hit.
Vadim
What do you think? Any other ideas, objections?
Regards,
Natalia
