Synchronous event listener

[Roman Puchkovskiy-2]

Hi.

Jackrabbit contains interface SynchronousEventListener. Looks like, if you register listener implementing this interface through ObservationManager.addEventListener(), it will be notified of events before changes are persisted, not after.

Is it OK to use this interface? Or is it 'very internal' and used only for Jackrabbit implementation?

If we use a transaction (possibly XA transaction), will such listener be notified of changes just after transaction was committed, or is there chance that transaction rolls back after listener was notified?

Thanks in advance.

[Marcel Reutegger]

Roman Puchkovskiy wrote:
> Jackrabbit contains interface SynchronousEventListener. Looks like, if you
> register listener implementing this interface through
> ObservationManager.addEventListener(), it will be notified of events before
> changes are persisted, not after.

no, this is not quite correct. synchronous event listeners are notified using
the same thread that commits changes, but only after they have been committed.

jackrabbit guarantees that a synchronous event listener sees items exactly as
they appear after the transaction has been committed. please note that this
guarantee only applies to item that were modified by the transaction.

> Is it OK to use this interface? Or is it 'very internal' and used only for
> Jackrabbit implementation?

it is OK to use it but only if you know exactly what you are doing ;)

why do you need a synchronous event listener?

> If we use a transaction (possibly XA transaction), will such listener be
> notified of changes just after transaction was committed, or is there chance
> that transaction rolls back after listener was notified?

no, that's not possible. event listeners (synchronous as well as asynchronous)
are only notified about changes that were successfully committed.

regards
  marcel

[Roman Puchkovskiy-2]

Hi, Marcel, thanks for explanations :)

In our application there're different ways to create data nodes. When 'data node' is created, we need to add some more records to other parts of repository (auxiliary data). Some of those different ways used for creation of data nodes are 'internal' (i.e. fully made by our code) - with them no problems exist: we just create 'data node' and auxiliary data in one transaction. But there're some 'external ways' to create data node (for instance, through WEBDav) where we need to react on creation of node and augment it with auxiliary nodes.

We decided that event listeners are what we need. But we need to create 'auxiliary data' for 'external modification' as soon as possible after creation of 'data node', and we thought that sync notification will be more convinient then async one. Maybe we're just fooled by fact that some systems treat async notification as low-priority process which may happen in any moment in future...

How do you think, does this make sence or async event listener will be enough?

Marcel Reutegger wrote:

why do you need a synchronous event listener?

[Marcel Reutegger]

Hi Roman,

if you need to write auxiliary data on modifications then you should rather use
async notification because you should not modify content in an synchronous event
listener. it is true that there is no guarantee when an async event listener is
called, but usually that happens only a short time after a change was committed.

regards
  marcel

Roman Puchkovskiy wrote:

> Hi, Marcel, thanks for explanations :)
>
> In our application there're different ways to create data nodes. When 'data
> node' is created, we need to add some more records to other parts of
> repository (auxiliary data). Some of those different ways used for creation
> of data nodes are 'internal' (i.e. fully made by our code) - with them no
> problems exist: we just create 'data node' and auxiliary data in one
> transaction. But there're some 'external ways' to create data node (for
> instance, through WEBDav) where we need to react on creation of node and
> augment it with auxiliary nodes.
>
> We decided that event listeners are what we need. But we need to create
> 'auxiliary data' for 'external modification' as soon as possible after
> creation of 'data node', and we thought that sync notification will be more
> convinient then async one. Maybe we're just fooled by fact that some systems
> treat async notification as low-priority process which may happen in any
> moment in future...
>
> How do you think, does this make sence or async event listener will be
> enough?
>
>
> Marcel Reutegger wrote:
>> why do you need a synchronous event listener?
>>
>