[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: |
|
||||||||
| Template: |
|
||||||||
| Acceptance criteria: |
Empty
|
||||||||
| Date of First Response: | |||||||||
| Description |
|
Maintain user transaction on subscriber while receiving content. |
| 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 |
| 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
B) message queue (JMS)
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. |