Transactions in CRX.

Lokesh BS wrote...

You can use a single session for a transaction and save only at the end of that session. In failover cases, it would rollback as the session wouldnt have saved with any of the changes.

 

This should be enough for single-threaded scenarios, but is CQ5 smart enough to handle multi-threaded scenarios without explicitly starting and committing a transaction?

Thanks.

First, if you want your changes to get comitted, you need to call session.save(); otherwise any change done within this session is getting discarded. As a second point I want to mention, that you should not use multiple threads to write to a single session. Instead each thread should use its own session. If your work needs to be done by multiple threads, you shouldn't directly write to the session.

IIRC it's working in the meanwhile (you won't break something), but strongly discouraged because of severe performance impacts.

Jörg

By multi-threaded I was referring to an app server, in which each request is handled by its own thread.

What happens in a scenario like this:

Request 1                                                  Request 2 ======================================================================================= create node at /content/foo with property p = FOO_1 create node at /content/bar with property p = BAR_2 create node at /content/bar with property p = BAR_1 create node at /content/foo with property p = FOO_2 session.save() session.save()

When the sessions are saved, what would end up in the repository?

Also what is the isolation level supported by CQ5/TarPM? Read Committed, Repeatable Reads, etc.?

Thanks.

Jorg,

There are scenarios in which we call some CQ APIs, and these APIs call save internally. For example, PageManager.touch saves the node immediately.

So even if I don't call session.save in my code, some changes might still be committed without using an explicit transaction manager.

As we are using TarPM and it is transactional, is there a way to expose a JCR transaction manager, etc. to have total, explicit control over transactions?

Thanks.

Hi

IIRC there is a transaction manager in jackrabbit available, but I never saw it used in the AEM context. Yes, some API implementations internally do the session.save() themselves, which can be problematic. But you cannot bypass it when you use this API.

I would recommend to raise a Daycare ticket for this behaviour. But I would not expect to get a changed implementation with a hotfix :-|

kind regards,
Jörg

Hi,

In that case, the second save() call would fail. /content/foo would have p = FOO_1 and /content/bar would have property p = BAR_1.

You should assume Read Committed, although Repeatable Reads is supported in a few contexts (especially with Oak).

Regards,

Justin

Thanks Justin for the clarification.