Spec Question

[Keith Rosenfield]

Hello All,
Before I ask my question, I would like to wish all Javaranch members a happy, healthy and prosperous New Year. BTW..I have even more to celebrate due to the fact that tommorow is my birthday.
And now for my question. In section 10.3.8 of the spec there is a bullet point that says the following.

� It is the responsibility of the Container to throw the java.lang.IllegalStateException
if an attempt is made to modify a container-managed collection corresponding to a multivalued
cmr-field using the java.util.Collection API outside of the transaction
context in which the collection object was initially materialized.

This point is unclear to me. What is meant by "the transaction context in which the collection object was initially materialized?" Can you describe a scenario where this might happen. Why is this not permitted?
Thanks,

[Philippe Maquet]

Hi Keith,
With the time difference, your "tomorrow" is very close to my "today", so : Happy birthday !

What is meant by "the transaction context in which the collection object was initially materialized?"

It's a bit unclear, because the specs state that the Container must garantee that the collection's *identity* never changes. But the whole stuff is more understandable : think of the fact that each time you change a CMR-field collection content, the Container has a (or a few of) db operations to perform. And to do it, it needs a meaningful transaction context.
Now for a possible bad scenario : clearing a CMR-field collection from within ejbActivate() or ejbPassivate(), two methods which run with an unspecified transaction context. But who would ever imagine doing that ?
Regards,
Phil.
[ December 29, 2003: Message edited by: Philippe Maquet ]

[Keith Rosenfield]

Thanks Phillipe,
I suppose it will be my birthday in France(you are in France, aren't you) before America.
I'm still a little confused. Why can the collection be modified in a new transaction context? For example,
- a collection is created in transaction context A
- transaction context A completes
- transaction context B initiates
- why can't the collection be modified now? It is in a valid transaction context.

Thanks again,

[Philippe Maquet]

Hi Keith,

I suppose it will be my birthday in France(you are in France, aren't you) before America.

I am in Belgium, but at the same time as in France.

I'm still a little confused. Why can the collection be modified in a new transaction context? For example,
- a collection is created in transaction context A
- transaction context A completes
- transaction context B initiates
- why can't the collection be modified now? It is in a valid transaction context.

I am now confused too. Thank you for that ! (I am sincere : questions which confuse you are the only ones which help you learn more... )
What's confusing IMO is that the specs are too much precise here because it describes in 4 lines something obvious :
When you read this (first bullet of section 10.3.8) : "It is the responsibility of the Container to preserve the runtime identity of the collection objects used in container-managed relationships.", you conclude : it's OK to store a reference to that collection in some instance variable for instance. And it's OK IMO.
Now *when* is that collection refreshed ? To simplify (commit option C), it will be in (or just before) ejbLoad() in the sequence ejbActivate() / ejbLoad() / business method / ejbStore() / ejbPassivate().
So, to take your example, the collection will be "materialized" (word used by the specs) in ejbLoad() / transaction A. If transaction B corresponds to another business method, it's still OK to modify the collection, because it has been refreshed in another ejbLoad() through a similar sequence, right ?
But once you're out of such transactional boundaries within which the collection was refreshed (in ejbActivate(), ejbPassivate() or (worst !) a home business method), the Container *must* complaint.
Now *if* I am right (hope Kathy will confirm/infirm), it's so obvious that the specs had better been written in a simpler way.
Regards,
Phil.

[Kathy Sierra]

Howdy -- I'm too brain-fried to look at that in the spec right now, and I'm not entirely sure what it's referring to. (I can tell you that this issue is not part of the exam). But... I just had to post to say Happy Birthday... and guess what? Tomorrow (Dec. 30) is also Bert's birthday!!
So enjoy!!
cheers,
Kathy

[Keith Rosenfield]

Happy birthday Bert.

CHEERS

[Rashmi Tambe]

• It is the responsibility of the Container to throw the java.lang.IllegalStateException
if an attempt is made to modify a container-managed collection corresponding to a multivalued
cmr-field using the java.util.Collection API outside of the transaction
context in which the collection object was initially materialized.

This behaviour is not only observed in collection modification but also in accessing the collection. I faced problem while reading the collection of multivalued cmr-fields. A session bean method (tx attribute - not supported) traverses the collection of multivalued cmr-fields . I got the IllegalStateException.
Then i changed the tx attribute of the session bean method and also the cmr field accessor method in a entity bean to 'Required' and the same code worked.
So now its mandetory for me to keep the tx attribute as 'Required' even if i dont want to
Why is it mandetory that reading a multivalued cmr-field collection has to be in a transaction? I think the readonly access shd be allowed w/o the transaction.
[ December 30, 2003: Message edited by: Rashmi Tambe ]

[Philippe Maquet]

Happy Birthday, Bert !
Hi Rashmi,

Why is it mandetory that reading a multivalued cmr-field collection has to be in a transaction? I think the readonly access shd be allowed w/o the transaction.

Because what's you read must be in synch with the DB. And as synchronization with the DB happens within transactions...
Regards,
Phil.

[Vishwa Kumba]

Happy BirthDay Bert and Keith!

Why is it mandetory that reading a multivalued cmr-field collection has to be in a transaction? I think the readonly access shd be allowed w/o the transaction.
--------------------------------------------------------------------------------
Because what's you read must be in synch with the DB. And as synchronization with the DB happens within transactions...

Is that true always?... I couldn't find more information about this in the spec and HF EJB also...

[Reid M. Pinchback]

Originally posted by Keith Rosenfield:
This point is unclear to me. What is meant by "the transaction context in which the collection object was initially materialized?" Can you describe a scenario where this might happen. Why is this not permitted?

I believe the spec is trying to allow for two different issues:
1. Give the container vendor some flexibility in deciding how and when to perform database operations. I think the assumption people are making is that an execution sequence like the following has taken place:
1. start a transaction
2. perform a database operation
3. create a new Collection (e.g. ArrayList)
4. put everything found in the database operation into the Collection
5. return the Collection
6. end the transaction
7. the Collection is in my hot little hands, transaction can't be relevant.
Steps 3 and 4 are the trouble spot. We don't know what kind of Collection it is, and we don't know when stuff is put into the Collection, not really. You could have some really subtle Collection implementation that wraps a database cursor. This may sound wierd, but imagine a relationship involving millions of items... you aren't going to want to instantiate all those entity beans right away. It would be better for a vendor to do two queries, one for the count (so Collection.size() works) and a second to open a cursor for the rows of entity data.
2. The other, probably more fundamental problem, is that without a transaction you don't know if it is ok to operate on the CMR data. Think about it... when you get that data you want to believe that the relationship is real. If two different clients are operating on similar data, that relationship could be morphing from moment to moment. If you have a transaction, then the container has asked the database for 'select for update' locks on the relevant data.... you can do what you need to do. Once the transaction is gone, the row locks are gone. The relationships may no longer be valid.

[Bert Bates]

Happy Birthday Keith!!