Thank you very much for your answer Dominique. It confirms our intuition.
I think that we will use the two modes, without transaction for
initialization (massive upload) and with transaction for the usual upload.Kind regards, Vincent. Dominique Pfister wrote: > > Hi Vincent, > > I'm not familiar with SJSAS, but as you correctly pointed out, every > modification is written to a memory-based "change log", until the > overall change is committed. This may result in an OutOfMemoryError if > the changes exceed the available memory. Setting your connector > transaction level to "NoTransaction" might actually remedy this issue, > but keep in mind, that some file uploads may then fail while other > succeed, leaving you in the situation of manually cleaning up whatever > might have gone wrong. I'd recommend to keep the transaction level and > upload smaller amounts of files, which is still not optimal but > probably easier to handle in case of an error. > > Kind regards > Dominique > > On 6/21/07, Vincent Guerin <[EMAIL PROTECTED]> wrote: >> >> Hi, >> >> Our project processes quite a lot of files (zip and XML) their size >> ranges >> from a few bytes to one (or few megabytes). We are storing on a complex >> tree >> structure on jackrabbit. >> >> For that purpose, we are using two stateless EJB, one for internal needs >> (business logic) and one as an API to use jackrabbit (that EJB is used to >> connect to the JCA connector – by Resource annotation). >> We are using the default storage system of Jackrabbit >> (org.apache.jackrabbit.core.fs.local.LocalFileSystem). >> >> This project is working fine on a limited number of files but generates a >> memory overflow (java.lang.OutOfMemoryError: Java heap space) whenever we >> are switching to real mode with a huge amount of files. >> >> After a few tests, we are guessing that the problem comes from the fact >> that >> the transactions commit (actual recording of the data in the repository) >> is >> only done at the end of the process (at the end of the EJB business logic >> process). >> >> Is it possible to make commit of a relative form throughout our process >> and >> if yes, how ? >> In other words, can I force the writing on the disk as fast as possible >> (directly into the repository in fact) ? >> >> Under SJSAS if I set the « Transaction Support » of my Connector >> Connection >> Pools to « No Transaction », would it solve my problem ? >> >> Vincent Guerin. >> >> >> The exception : >> >> javax.ejb.TransactionRolledbackLocalException: Exception thrown from >> bean; >> nested exception is: javax.ejb.EJBException >> javax.ejb.EJBException >> at >> com.sun.ejb.containers.InvocationHandlerUtil.throwLocalException(InvocationHandlerUtil.java:99) >> at >> com.sun.ejb.containers.EJBLocalObjectInvocationHandler.invoke(EJBLocalObjectInvocationHandler.java:195) >> at >> com.sun.ejb.containers.EJBLocalObjectInvocationHandlerDelegate.invoke(EJBLocalObjectInvocationHandlerDelegate.java:118) >> at $Proxy49.processIncomingFiles(Unknown Source) >> at >> com.dalloz.download.ejb.ProcessDownloadBean.downloadFilesFromFTP(ProcessDownloadBean.java:61) >> 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:597) >> at >> com.sun.enterprise.security.application.EJBSecurityManager.runMethod(EJBSecurityManager.java:1050) >> at >> com.sun.enterprise.security.SecurityUtil.invoke(SecurityUtil.java:165) >> at >> com.sun.ejb.containers.BaseContainer.invokeTargetBeanMethod(BaseContainer.java:2766) >> at >> com.sun.ejb.containers.BaseContainer.intercept(BaseContainer.java:3847) >> at >> com.sun.ejb.containers.EJBLocalObjectInvocationHandler.invoke(EJBLocalObjectInvocationHandler.java:184) >> at >> com.sun.ejb.containers.EJBLocalObjectInvocationHandlerDelegate.invoke(EJBLocalObjectInvocationHandlerDelegate.java:118) >> at $Proxy48.downloadFilesFromFTP(Unknown Source) >> at >> com.dalloz.download.ejb.ProcessDownloadMDB.onMessage(ProcessDownloadMDB.java:68) >> 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:597) >> at >> com.sun.enterprise.security.application.EJBSecurityManager.runMethod(EJBSecurityManager.java:1050) >> at >> com.sun.enterprise.security.SecurityUtil.invoke(SecurityUtil.java:165) >> at >> com.sun.ejb.containers.BaseContainer.invokeBeanMethod(BaseContainer.java:3866) >> at >> com.sun.ejb.containers.interceptors.AroundInvokeChainImpl.invokeNext(InterceptorManager.java:414) >> at >> com.sun.ejb.containers.interceptors.InterceptorManager.intercept(InterceptorManager.java:188) >> at >> com.sun.ejb.containers.BaseContainer.intercept(BaseContainer.java:3839) >> at >> com.sun.ejb.containers.MessageBeanContainer.deliverMessage(MessageBeanContainer.java:997) >> at >> com.sun.ejb.containers.MessageBeanListenerImpl.deliverMessage(MessageBeanListenerImpl.java:61) >> >> >> -- >> View this message in context: >> http://www.nabble.com/Transaction-problem-with-the-JCA-connector-under-Sun-Java-System-Application-Server-Platform-Edition-9.0_01-%28build-b02%29-tf3957491.html#a11229447 >> Sent from the Jackrabbit - Dev mailing list archive at Nabble.com. >> >> > > -- View this message in context: http://www.nabble.com/Transaction-problem-with-the-JCA-connector-under-Sun-Java-System-Application-Server-Platform-Edition-9.0_01-%28build-b02%29-tf3957491.html#a11232232 Sent from the Jackrabbit - Dev mailing list archive at Nabble.com.
