CMR throws 'can only be used in transaction in which it was

[ahardy66]

I ran a few CMRs happily with transactions set to 'Required', but now I am setting only the create, update & removes to 'Required' and I set the rest via the whole class * catch-all to 'Supports'.

JBoss throws the CMR exception, 'collection can only be used in transaction in which it was created'.

This is a read-only situation and I don't want any transactions, but it isn't recognising the 'Supports' nor 'NotSupported' which I also tried.

Is CMR only compatible with 'Required' transaction status?

Thanks
Adam

[sesques]

This is the EJB Spec. Collections returned by a getter on a CMR field must be used within the transaction in which it was created.
The transaction type concerns the EJB's propagation and normally, the transaction type set to "required" is the best solution.

Your error occurs certainly because you are using an EJB from a client (servlet or application). In this case, you must use a UserTransaction.

[ahardy66]

Thank you for replying, sesques

Actually this is in a Session bean and I'm getting the local home for the bean I want and then calling its getChildren method.

I don't need a transaction in this case and transactions will slow the performance down, surely?

Are you absolutely sure about it being part of the spec? It seems to take away a large part of CMR's usefulness - at least in my app where I am displaying lists of objects with child objects etc. in a read-only context.

Adam

[sesques]

Yes, it is defined to set accessors. In the 2.1 spec (I only have this one under my hand), this is this paragraph:

10.3.6.2 Use of Set Accessor Methods to Update Relationships

I don't try the readonly feature on beans. Perhaps you can. But the container is not aware of your read only intention. It must care about your collection manipulations

[ahardy66]

OK, thanks again. Actually I think I'm jumping the gun a little in my disappointment that I couldn't set the transaction level as I wished.

I shall have to stress test the app at some point anyway, so if I see performance problems down the line, then I know I can reprogram my methods to avoid CMRs for fetching read-only data. I'll look at the read-only attribute then as well - although I would prefer to stay container-independent.

Thanks & regards
Adam