TopLink 9.0.4 to 10.1.3.1 upgrade issue

Question

I've encountered a problem when upgrading our application from TopLink 9.0.4 to 10.1.3.1. I have a persistent class AccountPosition that contains an aggregate object instance of the class FundQuantity. FundQuantity is basically a wrapper for a java.math.BigDecimal, and it's meant to be non-mutable (just like a String, a BigDecimal, an Integer, etc.). I have a special constant FundQuantity.ZERO that contains the value BigDecimal 0. The AccountPosition default constructor initializes its enclosed FundQuantity to FundQuantity.ZERO. Our application creates a new AccountPosition with a FundQuantity of - say - 100, and makes it persistent via UnitOfWork#registerNewObject(). After the UnitOfWork commits,
FundQuantity.ZERO contains the value 100 - i.e., the constant is corrupted.
Here's what seems to cause the problem. When the application calls UnitOfWork#registerNewObject(), TopLink creates a hidden AccountPosition object by calling AccountPosition's default constructor. This hidden object has the FundQuantity set to FundQuantity.ZERO. At commit time, TopLink tries to merge changes from the application's AccountPosition object into its hidden object. Rather than creating a new FundQuantity object (as it's the case when reading an AccountPosition from the DB), the merge operation overwrites the BigDecimal that's stored inside the FundQuantity. The stack traces shows a call to TopLink's AggregateMapping#mergeChangesIntoObject(). The source code for AggregateMapping - part to toplink-src.zip - has the following comment:
//Bug#4719341 Always obtain aggregate attribute value from the target object regardless of new or not
A few lines below, TopLink builds a new instances of the aggregate only if the target aggregate reference is set to null or its class doesn't match that of the source aggregate. If AggregateMapping#mergeChangesIntoObject() always built a new FundQuantity, our application would probably work fine. Since this problem does not occur in TopLink 9.0.4, I'm wondering if it's related to bug 4719341. Does anybody have any ideas?

Answer 1

Chris,
Thanks for your feedback.
>
The problem you are encountering is that aggregates
in TopLink are not considered immutable and are not
meant to be shared. They are treated as objects
completely dependent on the owning object, such that
they cannot be shared. If the FundQuantity classWhen I'm reading an AccountPosition from the DB, TopLink does create a new FundQuantity aggregate - even though the default AccountPosition already contains a FundQuantity set to FundQuantity.ZERO. In other words, when performing a read, TopLink treats the FundQuantity as a mutable. It's only when merging the aggreagate that, in TopLink 10.1.3, TopLink treats the aggregate as an non-mutable. Do you agree?
only persists the BigDecimal, you may wish to use a
transformation mapping to convert it to/from a
BigDecimal in the database instead.
That would work for FundQuantity. However, we have another aggregate class that contains both a BigDecimal and a String. For that class, we need to use an aggregate mapping.
Would it be possible to add a new option setIsMutable(boolean) to the aggregate class descriptor - not the AggregateDescriptor object, the Descriptor on which we call descriptor.descriptorIsAggregate(). Based on the option's value, TopLink could decide what to do - whether to create a new aggregate or to modify it. If the aggregate is mutable, TopLink could avoid creating a new instance both on read and on merge - unless it's null. If it's non-mutable, TopLink would always create a new instance.