On 7 May 2009, at 07:55, Felix Meschberger wrote:
Hi,
Ian Boston schrieb:
On 6 May 2009, at 20:23, Felix Meschberger wrote:
I have to admit, that I have my issues with this patch, too. First
it
introduces new API and second it exposes a Jackrabbit internal
feature
(SynchronousEventListener) which is AFAICT not intended for
general use.
May I ask you, what your use case for the SynchronousEventListener
is ?
We need to get access to items before they are saved to
a) set additional node properties
b) apply some rules on node properties.
Hmm, not knowing the exact details, I would assume that in your
synchronous listener you have a JCR session, which you use to update
the
content.
So it would be something like:
User Session US modifies content
Synchronous Listener gets notified
Synchronous Listener Session SLS modifies content again
yes, but in some cases there is more.
Correct. Now, I don't completely understand what the advantage of
using
a synchronous listener really is - or is it for the "Transaction
Context" you are referring to below ?
I'll add a some context.
We have bound a JTA transaction to the JCR session (using the
XASession methods) That transaction is committed at the end of the
request cycle.
The JTA transaction is also bound to a JPA Entity Manager so that all
modifications are committed at once... or rolled back at once.
Some, not all, of the Synchronous listeners update relational indexes
stored in a traditional RDBMS via JPA and used for reporting type
queries that are not possible through the JCR Query mechanism.
Important, but not directly relevant
We run in a cluster and with the JTA transaction bound to the session
the volume of journal entries flowing through the cluster node is
greatly reduces. In short we see one large journal entry per request
cycle and a number of lock-unlock events. This was observed pre-sling
on JR14 after patching the Journal writers to filter out blank events.
For us... this had a large impact on back end database load. I haven't
re-tested on Sling with JR15 (yet), I believe there is an alternative
fix already in place for the empty event issue, but AFAICT binding the
a transaction to the request will have the same effect (as well as
mitigating failures part way through the request cycle)
To recap:
1. We events because we want to monitor all nodes for modifications to
certain properties, potentially changing those properties and vetoing
them.
2. We also generate relational indexes of node properties in JPA
managed tables so that views with multi table joins can be generated.
3. We use synchronous events because we need to bind into a single
transaction over both JCR and JPA, and potentially roll back the
entire transaction.
Now, the approach is a hack that works with what is possible, if there
is a more mainstream way of achieving the same results.... then I am
open to anything.
Ian
So I would also prefer a solution, which the standard OSGi Event
Admin
service: Using service registration properties EventHandler
services may
limit the events they receive.
To support Jackrabbit SynchronousEventListeners, the OSGi EventAdmin
bridge (bridging JCR events to OSGi events) may use synchronous
event
delivery (EventAdmin.sendEvent). For normal EventListeners, the
regular
asynchronous event delivery (EventAdmin.postEvent) is used.
WDYT ?
yes, that might work for us,
I assume by synchronous they are on the same thread
No, you cannot assume that you are running in the same thread, the
save
assumption as per the OSGi EventAdmin spüec is, that it may be the
same
thread must is not required to be. But you may assume that the
listener
is called synchronously.
and share the same Transaction context ?
I am not sure, what exactly you mean here. Is the listeners session
associated with the "Transaction context" while updating more
properties
? Now, the question is of course, how the listener session gets to the
"Transaction context" to associate with. If it is a ThreadLocal
property, you may be lost with EventAdmin.
Maybe Jackrabbit SynchronouseEventListener is so special, that we
expose
special API from the jackrabbit-server bundle to support such
synchronous listeners.
Regards
Felix
