Quoting Michael Smith <[EMAIL PROTECTED]>:
> Remy Maucherat wrote:
> >
> > I know, but I believe that's way too complex to implement in many
> cases.
>
> Why? We could easily have the move interfaces implemented in
> StandardStore.java as a copy/delete, as we do currently - then specific
> stores (like FileContentStore) that have a way to do things MUCH
> faster/more efficiently/more correctly can override that. Or are there
> interactions between the different stores (i.e. content vs. metadata)
> that would be too hard to control this way?
Yes.
The problems are :
- the data is split among multiple stores
- the fact that there's federation (if we move /foo to somewhere else, /foo/bar
may actually be in another store)
- that would also violate the ACL checking mechanism, unless you go down the
tree to check every node, but then the performance difference starts being
smaller
I believe it will be possible to have the fs store be transactional with the
default concurrency level (only one trasaction at a time, even inactive).
I really don't see a way how it can be done.
> > > - The permissions for deletion are checked after the copy
> operation.
> > > This means that you need to
> > > wait for the full copy operation (and it's rollback) before an
> error
> > > response is sent.
> >
> > True. We could add a check to see if the source can be deleted before
> doing
> > anything else.
>
> That would certainly improve the situation, but isn't a long term
> solution (see previous mail) unless you just want to serialise all
> store
> access (perhaps optionally - so stores which require it can ask for
> that, or something...) - but that'll really hurt performance in high
> load cases.
Yes, but there's no other choice. Basically, the operations on the store have
to be atomic for the reasons listed above.
Remy
