J. Wolfgang Kaltz wrote:
Hi all,
I'm trying to understand why saving in bxe does not work. IIUC it has to
do with the locking of the nodes which isn't working, but I don't
understand why:
1. when the editor is started, the nodes aren't locked as far as I can tell
2. when save is called in the editor :
2.1 edit-document.js::editDocument() is called (see usecase-bxe.xmap)
2.2 this calls AbstractUsecase's lockInvolvedObjects()
2.3 this tries to lock the nodes of the document, the URI seems
correct to me. But the nodes are already checked out, so this is an
error. The error is added to the usecase's error message; this currently
has no effect as error handling in edit-document still needs to be
implemented
2.4 the usecase's execute() is called, it fails with an exception
saying the node to be written to is not locked. The URI is the same as
above
I understand that the editor handling in currently a mixture of old
usecase framework and new usecase framework, because of problems getting
it to work in the new framework. What I don't understand is:
- why, when reaching 2.3, the nodes are already checked out, and who
checked them out
- why 2.4 fails. The nodes are not locked, but if they have been checked
out before 2.3, should they not also have been locked ?
The problem is quite complex, and I didn't yet find a solution.
In 1.4, you can write to a source only inside a transaction, which requires
a UnitOfWork object. The usecase framework manages this by attaching the
UnitOfWork to the request, so that it is available to the LenyaSourceFactory.
Basically, passing the transaction from request to request is done through the
continuation ID.
AFAIK BXE doesn't allow to change the BX_xmlfile parameter after each
"save" action, which would be necessary to pass the continuation ID
from request to request.
A workaround could be to add the continuation ID to the session.
Another option is to write the XML to a temporary source and copy this
temp source to the original source when the user exits BXE.
To be honest, I don't really understand the new locking / checking out
mechanisms on the objects (talking about objects as in instances of
classes, not talking about the rc checkout here).
I started some docs, feel free to add your questions / comments:
http://wiki.apache.org/lenya/OverviewRepository
IIUC
- object lock is there to prevent 2 users working at the same time
changing the same object
Yes, and to prevent an object from changing its state between several read
operations in a transaction.
- object lock is implemented via the UnitOfWork; the UnitOfWork is used
both for accessing documents and for changing them, so some custom
mechanism is required to avoid 2 people changing an object at the same
time.
What I don't understand is
- What is the difference between lock and checkout ? And why does it
cause a problem in the edit usecase ?
Lock is used to notice changes, checkout is used to avoid changes.
- (design question): would it not be easier to explicitly separate read
and potential write accesses ? i.e. reading could be possible without a
unit of work,
It is possible without a unit of work ... what do you mean?
but to write one needs to retrieve a unit of work. If this
were so, it should be sufficient to mark all the unit of work's methods
as synchronized, as thus avoid the custom implementation of object locking?
I don't really understand this, could you give an example?
-- Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
