Hi Alex
: comments below
On Sep 17, 2005, at 5:40 PM, Alexandru Popescu wrote:
Magnolia Transactional Activation
_Intro_
According to the discussion I had with Mr.Sameer Charles, it seems
that the activation process [1] is not transactional.
A 2nd remark about the activation process is that currently there is
no standard way to do it. Magnolia is offering two completely
different mechanisms: SimpleActivation and export/import capabilities
(as specified in the JSR170). There where plans to have the activation
mechanism implemented according to Internet Content Exchange [2] spec,
but it was too complex.
A 3rd important aspect of the activation process is the possibility to
have incremental delivery [3].
_Possible approaches_
In the 1st place it seems to me that activation transactionability and
incremental delivery are not directly related. Indeed taking into
account that adding transactional support to a much complex operation
like incremental delivery may sound more complex, we are trying to
find a solution that will not be influenced by this (we must keep in
mind that the operation that *must* be transactional is the *save*).
_Transactions_
The most important aspect of the activation process transactions looks
to me to be the fact that this process involves more than 1 system;
even more these systems are independent and not homogenous (they are
not supposed to have the same nature).
Having in mind this, I think that what describes best this kind of
transaction is an XA transaction (or a 2-phase commit transaction).
_Scenario description_:
Let’s assume the following: A is the authoring system, and P1, ..., Pn
are the subscribers. A transaction is supposed to work as follows:
1. A begin transaction
2. A triggers activation action for P1, ..., Pn
3. Pk begin transaction; if everything goes well informs A that it
is successfull
4. if all Pk have reported a SUCCESS state than A commit =>
triggers the commit action on all Pk
5. if there is at least 1 FAILURE state reported by Pk than A
rollback => triggers the rollback action on all Pk
I am not sure if a single failure should rollback from all Pk, this
might not work for installations like news agency which could deliver
content to hundreds of subscribers. If we maintain proper history for
all subscribers we can always update those subscribers which were
failed.
in my opinion every subscriber should be treated as a single entity
rather than as a group,
I know this will add more complexity but if we are doing it good lets
do it better :)
6. A close transaction
There are 2 more things to specify:
1. if an error occurs after A commit (or at any level of subsequent
Pk commits) than a HeuristicRollbackException should be thrown marking
that the system is in an unknown final state
2. if an error occurs after A rollback (or at any level of
subsequent Pk rollbacks) than a HeuristicCommitException should be
thrown marking that the system is in an unknown final state
_Additional_:
* JSR170 in its Chapter 8.1 talks about transactionability in
terms of optional features. In case a repository is not offering
transactionability support than other solution can be used.
ll stick with jcr transaction support, Its an optional feature but I
would expect all good jcr implementations to have this. If not what do
you suggest?
* Afaik Jackrabbit is offering an implementation of the full
JSR170 spec, so it includes support for transactions.
_Incremental delivery_
without incremental delivery activation process might become unusable
after thousands of nodes in a repository. For a simple website its
really not needed
but more and more people are using magnolia for big websites / dms
etc..
TBD
_Open questions_
* upon activation of a resource URL (URI?) all the children are
pulled?
Hmmm, its hard to define, since same base system will be used for other
applications like DMS, and there structure of a resource will be
completely
different than on WCM.
Would be great if we can find a way to configure this, for instance in
WCM you can specify if mgnl:content (page) type is activated all sub
mgnl:contentNode (containers/paragraphs) are pulled.
[1] activation process is the action that triggers the synchronization
between the authoring repository and all registered public subscriber
repositories.
[2] ICE specifications are available here
[3] Description scenario: you have 2 subscribers A and B; you
activated /home which includes 2 images and 2 paragraphs; now one
author added 1 new paragraph to this page and also added one new
subscriber C; after this if someone activates /home A and B should
only recieve this new paragraph and C should receive the whole
content. Only this missing is this history information, what what part
is already sent to which subscriber.
Please add your comments to the above proposal. Your help is needed
and highly appreciate.
Thanks for your time,
./alex
--
.the_mindstorm.
----------------------------------------------------------------
for list details see
http://www.magnolia.info/en/magnolia/developer.html
----------------------------------------------------------------
----------------------------------------------------------------
for list details see
http://www.magnolia.info/en/magnolia/developer.html
----------------------------------------------------------------
