Hi Rob, On 11/19/07, Rob Hills <[EMAIL PROTECTED]> wrote: > > Hi Michael, > > Thanks for the reply. > > Michael Horwitz wrote: > > > > On 11/19/07, *Rob Hills* <[EMAIL PROTECTED] > > <mailto:[EMAIL PROTECTED]>> wrote: > > > > > > After chipping away at this all weekend I'm still stuck. To > > summarise the problem (detailed previously in this thread), I have > > a form that simultaneously edits a Parent record and its related > > child records (I'm calling the POJOs "Parent" and "Child" for > > simplicity) but when I try and post changes, I get a Hibernate > > InvalidDataAccessApiUsageException: "write operations are > > not allowed in read-only mode (FlushMode NEVER/MANUAL)". > > > <..> > > > > > > My questions are: > > > > 1. Is my hypothesis about the Job entiy being a cause of the > > problem worth investigating, or is it unlikely? > > > > > > The "read only transaction" issue is normally down to your managers > > being correctly intercepted by the Spring transactional wrappers, > > which is entirely down to how your managers are wired together and how > > they are then wired into the relevant actions. Normally the stack > > trace is a good place to start - put a debug point in a method that > > works on a DAO/Manager that saves an object, take a look at the > > interceptors that get invoked, place a similar debug point on the > > method that does not and compare stack traces - if the interceptors > > are missing, therein lies your problem. > > > I've been doing quite a bit of tracing through the code (via Eclipse) > but am having a bit of trouble understanding what I'm looking at. What > would the "interceptors" look like - are they likely to have > "interceptor" in the classname? If not, are you able to suggest a class > name that's an example of what I might be looking for?
As an example, here is one I copied out of Eclipse while paused at a breakpoint: NativeMethodAccessorImpl.invoke0(Method, Object, Object[]) line: not available [native method] NativeMethodAccessorImpl.invoke(Object, Object[]) line: 39 DelegatingMethodAccessorImpl.invoke(Object, Object[]) line: 25 Method.invoke(Object, Object...) line: 585 AopUtils.invokeJoinpointUsingReflection(Object, Method, Object[]) line: 296 ReflectiveMethodInvocation.invokeJoinpoint() line: 177 ReflectiveMethodInvocation.proceed() line: 144 HibernateInterceptor.invoke(MethodInvocation) line: 104 ReflectiveMethodInvocation.proceed() line: 166 TransactionInterceptor.invoke(MethodInvocation) line: 107 ReflectiveMethodInvocation.proceed() line: 166 JdkDynamicAopProxy.invoke(Object, Method, Object[]) line: 204 $Proxy32.executeRule(Object, String, ResultExtractor) line: not available You are interested in the bits between $Proxynn.methodName() and NativeMethodAccessorImpl.invoke() (after which your manager method should appear). In the above example the HibernateInterceptor is being invoked as well as the TransactionInterceptor. The example is not from an AppFuse application, but you should see very much the same in your code - the interceptor you are interested in is the TransactionInterceptor. I find the above to be really useful for making sure my join points are working properly and that my advice elements are being called in the correct order. Mike TIA, > > Rob Hills > Waikiki, Western Australia > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
