On 11/19/07, Rob Hills <[EMAIL PROTECTED]> wrote: > > Hi All, > > 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)". > > I have been focusing on the Parent-Child relationship and the > JPA/Hibernate Annotations in the POJOs that I'm using to > express this. I did find some errors - I'm regularly amazed at the levels > of developer stupidity that Hibernate will tolerate with > nary a smirk, let alone an error message or compile error :-( - but fixing > those hasn't got rid of the problem. > > It then occurred to me that the problem may lie outside this > relationship. Both Parent and Child have their own one-many > relationships so I examined all these and tweaked the annotations so they > were all consistent. Still no joy. > > I'm now considering the possibility that my problem is due to a > lookup. In my "Child" entity, I have an attribute named > "jobCode". This has no defined relationship, but on the data entry form, > it's supported by a combobox that sources its list > from a "Jobs" list. This list is provided via a JobManager in my > ParentAction class -> JobDaoHibernate -> a list of Job > entities. The Job entity actually fronts a read-only view from the > Database. So, I'm wondering if this "read-only" entity is > somehow causing the whole transaction to be flagged as "read-only" even > though there's no formally mapped relationship > between the Job entity and my Child entity's "jobCode" attribute. > > 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. Mike 2. If it is a likely cause, I assume the best fix is to somehow > identify to Hibernate that Job is a read-only entity. I have > worked out that I can do that via a Hibernate annotation, but I've been > trying (successfully so far) to keep my annotations > pure JPA. Is there something I can do in the hibernate.cfg.xml file that > would achieve the same result? If so, what? TIA, > Rob Hills > Waikiki, Western Australia > Mobile +61 (412) 904-357 > Fax: +61 (8) 9529-2137 > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
