jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tobias Strasser <tobias.stras...@gmail.com>
Subject Re: versioning questions
Date Tue, 21 Jun 2005 19:27:28 GMT
> It seems versioning is not working as expected on the root node. It
> fails to create a versionhistory (VH) if the root node in another
> workspace already has a VH. Apparently, it's the result of using the
> same uuid for the root node in multiple workspaces.
> I get the following exception
> javax.jcr.version.VersionException: History already exists for node
> cafebabe-cafe-babe-cafe-babecafebabe
> Is there any reason for using the same uuid? I think it might lead to
> errors in the client code. AFAIK the root node is the only node that
> can share the uuid and not the VH.
no, several (corresponding) nodes in different workspaces can have the
same uuid (see Workspace.clone()). this is the basic idea of
versioning and workspaces. this implies, that the root nodes of all
workspaces must have the same uuid. the exception you describe is a
bug. of course it must be possible to version corresponding nodes.

assume the following:
- create node N1 in Workspace W1
- clone node N1 to Workspace W2 -> N2 (corresponding node)
- make N1 versionable -> VH gets created
- make N2 versionable, or update N2 -> N1 and N2 share the same version history

> A couple of doubts ... Since there are two separate instances of PMs
> handling any versioning action, one for the workspace, and another for
> the versioning, and versioning actions are not synchronized, how can
> versioning be thread safe?, I mean that not necessarily the threads
> will write to both PMs in the same order. And for the same reason (2
> PMs for 1 action) it seems it won't be possible to persist versioning
> changes as a unit in a single transaction. Comments?

well, thread-safeness an transactions are different things.

under thread-safe i understand, that 2 or more threads accessing an
application do not corrupt the internal structure or crash the VM (eg.
unsynchronized hashmap accesses, etc.)
transactional integrity is defined via isolation levels (e.g. see
[1]). i assume, that 2 threads, committing modifications in 2
different transactions, do whatever isolation level is defined. in the
worst case, the second that commits, looses the changes. but the 2
transactions are in this respect thread-safe, that they do not corrupt
the data structure/integrity of the repository.

i admit, that i did not take extra care to thread-safeness in
versioning. it could be, that 2 threads, checking-in separate versions
(or the same) could corrupt the repository.

one thing I'm 100% sure about is, that versioning does not take part
of the transactions used for the rest of the repository, yet. for

- begin transaction
- create node
- add mix:versionable
- save --> will create version
- checkin
- cancel transaction

this will leave a orphaned version behind, which is not desired.

the reasons, why we separated the versioning persistence, are:
- the jcr:versionStore is shared by all workspaces, thus why should it
be stored in default ws
- the requirements for a versioning persistence is completely
different from the rest of the repositories persistence (write once,
read many)

but i agree, that the versioning must be thread safe and should
participate in the respective transaction. i created 2 jira bugs,
JCR-140 and JCR-141.

cheers, tobi

[1] http://en.wikipedia.org/wiki/Isolation_(computer_science)

------------------------------------------< tobias.strasser@day.com >---
Tobias Strasser, Day Management AG, Barfuesserplatz 6, CH - 4001 Basel
T +41 61 226 98 98, F +41 61 226 98 97 
-----------------------------------------------< http://www.day.com >---

View raw message