Please consider this snippet from the ObjectEnvelope#getMap (Revision
1.17).
if (items != null)
{
// items might be a Collection or an array.
if (items instanceof Collection) // [A]
{
/*
* if items are a collectionproxy, and it's not already
loaded, don't register it.
*/
if (!( items instanceof CollectionProxy) ||
( (CollectionProxy) items).isLoaded()) //[B]
{
continue;
}
/**
* MBAIRD
* size isn't the safest thing to use as the dirty bit.
This will
* need to be fixed.
*/
Object dirtyMark = new Integer(((Collection)items).size
());
fieldValues.put(collectionDescriptor, dirtyMark);
}
else // items instanceof Object[]
{
Object dirtyMark = new Integer(items.hashCode());
fieldValues.put(collectionDescriptor, dirtyMark);
}
In Revision 1.17 has introduced a bug. The CVS metadata says this is in
response to BUG OJB131. I think addiition of line [A} is perfectly proper.
However, the meaning of the condition on line [B] has been totally
reversed. (Honest! I did a truth table). The consequences are very bad for
users of Non-Decomposed Collections (that's where we have problems ---
might be problem in other Collections).
Additionally, the comment about using size as the dirty bit is extremely
frightening to me, as that indicates a measurable quantity of changes to a
collection just won't be persisted.
I have a proposal to change the dirty-bit part of the code, but it involves
adding another method to the ManageableCollection interface. Essentially,
make it the responsibility of the collection to provide a digest (or
something similar) that can be used as a dirt bit. I'll be glad to right
it if you think that's an OK plan. If not, the only solution I can see is
to iterate over the list, building maps of each individual object, and then
making sure this collection of maps implements equals correctly.
As we're weeks away from our deadline, anything I can do to get this
working "correctly", let me know.
David
|---------+--------------------------->
| | [EMAIL PROTECTED]|
| | ifax.com |
| | |
| | 03/26/2003 10:39|
| | AM |
| | Please respond |
| | to "OJB Users |
| | List" |
| | |
|---------+--------------------------->
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|
|
| To: [EMAIL PROTECTED]
|
| cc:
|
| Subject: Non-Decomposed collections, without implicit locking
|
|
|
>--------------------------------------------------------------------------------------------------------------------------------------------------|
We've been using ND collections, and without realizing it, we had implicity
locking turned out.
It worked great in 0.9.9.
However, when we switched turned off implicit locking, and switched to rc1,
objects in the ND collection are not persisted.
Experimentation reveals this doesn't work in 0.9.9 w/o implicit locking,
and doesn't work in rc1 with or without implicity locking.
I've not yet debugged into OJB to see what it is doing, but I'm planning on
it.
Should this work still? Is anyone else having problems in this area?
David
This message contains information from Equifax Inc. which may be
confidential and privileged. If you are not an intended recipient, please
refrain from any disclosure, copying, distribution or use of this
information and note that such actions are prohibited. If you have
received this transmission in error, please notify by e-mail
[EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
