This page is totally out-of-date wrt to Lenya 2.0. – JörnNettingsmeier <<DateTime(2007-07-30T14:11:20Z)>>
Lenya 2.0 provides a basic repository implementation, which will probably be replaced by JCR (see ProposalRepository).
The repository is accessed via URLs using the lenya://
protocol. The root of the URL space is the servlet context directory, which means that the URL
lenya://lenya/pubs/mypub/content/authoring/index.xml |
accesses a content resource inside a publication.
When a URL of the form lenya://...
is resolved using the SourceResolver
, the LenyaSourceFactory
creates a RepositorySource
object. The repository source accesses the repository via a o.a.l.cms.repository.Node
, which provides the actual repository functionality. Currently, the Node
interface is implemented by the SourceNode
class, which accesses files using context://
sources. The Node
interface extends the Transactionable
interface, which means that a repository node is designed to be read and manipulated in transactions. It supports locking and versioning.
Imagine the following scenario:
Without special precautions, Alice's changes are lost. Locking is used to determine if a persistent item has been changed since it was read for the first time during a transaction. To use the item, it has to be loaded as an object. Before the first read access, a lock is placed on the object. The lock contains the current version number. When Alice saved the item A, Bob's transaction can now compare the current version of A with the lock version by calling Transactionable.hasChanged()
. This way, it can determine if A was changed during the transaction and output a warning message. This policy is called optimistic offline lock, because Bob's transaction was optimistic that no changes would occur during editing.
Another scenario:
Check-In and Check-Out are used to prevent a repository node from being changed by more than one client at the same time. A complex transaction might not want to use optimistic offline lock, because it would be too expensive to lose all changes if the affected node was meanwhile changed by another user. In this case, the node can be checked out in the beginning of the transaction. If a node is checked out, it cannot be locked. This means that no other transaction may begin which would affect the node - the node is protected from being changed by another user.
Whenever a change is made to a repository source, a new version is created. This is achieved using Lenya's revision controller.