[MGNLXAA-1] Implement transactional activation Created: 17/Nov/06  Updated: 04/Oct/13  Resolved: 02/Jun/08

Status: Closed
Project: Transactional Activation
Component/s: None
Affects Version/s: None
Fix Version/s: 1.0

Type: New Feature Priority: Critical
Reporter: Sameer Charles Assignee: Jan Haderka
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
relation
is related to MAGNOLIA-1274 memory: recursive activation creates ... Closed
Template:
Acceptance criteria:
Empty
Date of First Response:

 Description   

Maintain user transaction on subscriber while receiving content.
Currently on tree activation authoring instance sends multiple unrelated activation requests to subscribers which kills the cache after every successful
request and can also result in strange ordering if content is received from multiple sources



 Comments   
Comment by Philipp Bracher [ 17/Nov/06 ]

The original intention of spliting the requests was the saving of memory. The ordering problem is not solved be making bulk activation requests in my opinion, because one can also manually acitvate single pages in different orders.

But sure solving transactional behavior will be more difficult by sending multiple requests.

Comment by Boris Kraft [ 20/Nov/06 ]

A transaction is a start and an end point, and lots of stuff in between
I think it should be possible to build this with multiple requests.

Comment by Philipp Bracher [ 28/Nov/06 ]

Sure but means much work.

Comment by Philipp Bracher [ 16/Mar/07 ]

I propose two approaches:

A) use jackrabbit clustering

  • one public instance is the master
  • author activates to the master
  • data gets distributed by clustering

B) message queue (JMS)

  • author deposes activation package as a message
  • interested instances will read it from there

Variation A has the benefit of not needing any addition coding (assuming that clustering really works). B is using standards and existing infrastructures.

Currently I'm against of implementing a custom transaction mechanism solving the multiple instances problem. For me it looks a bit to complex.

Comment by Jan Haderka [ 02/Jun/08 ]

Current take on implementation is via temporary workspace at each target location with author as XA Coordinator.
Implemented in separate module to provide flexibility and backwards compatibility.

Generated at Mon Feb 12 11:06:05 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.