topic Re: RMI, JCR and the Giant Transaction (or lack there of) in Alfresco Archive

RMI, JCR and the Giant Transaction (or lack there of)

rdanner — Tue, 17 Jan 2006 21:22:50 GMT

I am connecting to Alfresco via RMI (jackrabbit) over the JCR interace. Per the new build I am throwing an exception in the Alfresco JCRProxyI start a transaction on my side (which does not result in any kind of synchronization on Alfresco's side (AlfrescoTransactionSupport) which leads trxId to ev

Re: RMI, JCR and the Giant Transaction (or lack there of)

davidc — Wed, 18 Jan 2006 18:37:01 GMT

Hi Russ,

We've yet to try out JCR-RMI in-house, so you're leading the way here!

How are you managing the transaction on your side?

Thanks

Re: RMI, JCR and the Giant Transaction (or lack there of)

rdanner — Wed, 18 Jan 2006 18:49:55 GMT

Hi Russ,

We've yet to try out JCR-RMI in-house, so you're leading the way here!

How are you managing the transaction on your side?

Thanks

Well,

I dont know if we will be going to production with RMI anyway. For now it was an easy way to put the repository outside of our work and behind a service layer (that eventually translates to JCR - RMI and finally alfresco)

Prior to yesterday I had been using JTA provided JOTM or in some test scenarios a fake/stub Transaction. To be completely honest I have yet to spend much grey power on transactions. Alfresco complained that I was operating outside a transaction so I started up JOTM got a transaction started and went on my way until I built 1.1.2 and got the exception above.

The thing there is if i am going to register a synchonization it should all happen magically somehow throught the JCR layer of alfresco because no one using JCR is going to know about a alfresco transaction service.

The Jackrabbit stuff looks good. I assume you guys are going to use it? They have done a lot to build client object so they can meet the JCR spec exactly and hide all the remote crap from the client. It seems good.

Personally I hate RMI and all it's nasty serialization and firewall issues; but like i said it's a quick remoting option (off the shelf) for us at the moment. We are looking at alternatives.

Re: RMI, JCR and the Giant Transaction (or lack there of)

davidc — Thu, 16 Feb 2006 17:14:23 GMT

Changes have been made to the way we integrate transactions into our JCR layer. I haven't tried the RMI layer against it yet, but it may now behave.

Re: RMI, JCR and the Giant Transaction (or lack there of)

rdanner — Fri, 17 Feb 2006 18:22:02 GMT

Changes have been made to the way we integrate transactions into our JCR layer. I haven't tried the RMI layer against it yet, but it may now behave.

Ill take a look at it in the next few days

Re: RMI, JCR and the Giant Transaction (or lack there of)

ananius — Sat, 04 Mar 2006 11:37:05 GMT

We are testing JCR-RMI in one project, and in Alfresco 1.2 the system works better.

But there's a problem: RMI calls (that should belong to same transaction) might happen in different threads on Alfresco's side. This leads to following exception (when the executing RMI thread is not the same that previously logged in to JCR): net.sf.acegisecurity.AuthenticationCredentialsNotFoundException: A valid
SecureContext was not provided in the RequestContext.

If we go past that doing authentication for example in custom JcrProxyFactory in different threads, next we will be getting this exception:

Exception in thread "main" java.lang.RuntimeException: UserTransaction may not be accessed by multiple threads
        at org.alfresco.util.transaction.SpringAwareUserTransaction.getTransactionInfo(SpringAwareUserTransaction.java:234)
        at org.alfresco.util.transaction.SpringAwareUserTransaction.rollback(SpringAwareUserTransaction.java:435)
        at org.alfresco.jcr.session.SessionImpl$InnerTransaction.rollback(SessionImpl.java:965)
        at org.alfresco.jcr.session.SessionImpl.logout(SessionImpl.java:654)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:585)
        at org.alfresco.jcr.util.JCRProxyFactory$SessionContextInvocationHandler.invoke(JCRProxyFactory.java:154)
        at $Proxy62.logout(Unknown Source)
        at org.apache.jackrabbit.rmi.server.ServerSession.logout(ServerSession.java:229)‍‍‍‍‍‍‍‍‍‍‍‍

How should we handle this?

Is it possible to access same transaction from different threads?
Or would it be wise for example to use own new thread per each JCR session, and run all the stuff in there from different RMI calls/threads?

Re: RMI, JCR and the Giant Transaction (or lack there of)

derek — Tue, 07 Mar 2006 12:10:19 GMT

Hi,

I haven't played with it, myself, but have you configured the Alfresco transactionManager to use the JTA transaction manager?

Regards

Re: RMI, JCR and the Giant Transaction (or lack there of)

steel — Mon, 19 Jun 2006 16:15:06 GMT

Any more updates to this? I am having the same issue.

thanks.

Re: RMI, JCR and the Giant Transaction (or lack there of)

mindthegab — Thu, 12 Jul 2007 15:16:40 GMT

One year later…
still no clue…
has anyone succeded to integrate *any* of the alfresco remote interface in a distributed JTA transactional environment?

See also this post:

http://forums.alfresco.com/viewtopic.php?p=24026&sid=e3aafb26e9381a5ff0c255f8c62178d7

For other resources…

Shall we give a boost at the JCR-RMI interface? How does it compare with roadmap from Alfresco?
Just to be clear, as a partner (Sourcesense) I'm facing customers which are a bit disappointed that an EnterpriseCM system do not provide any facility for enterprise transaction integration (JTA is mandatory for a J2EE compliant server).

But, don't take me wrong, Alfresco is still the best product on the market…clean and neat !

Hope this helps,
Gab

PS.
How do I get the "Alfresco Partner" little icon ? ))