I think you're talking about referential integrity across region entries -
meaning an object in one region entry's value is the same as an object in
another region entry's value, and you want them to refer to the same object.
Unfortunately, referential integrity is not maintained across region
entries. As soon as an entry is serialized and deserialized, referential
integrity is lost. Entries are kept in serialized form in almost all cases
(a local region being an exception). As soon as a client does a put or a
peer does a put into a partitioned region or entries are replicated between
members, the entry is serialized. So, with this case:
regionEntryA -> instrumentA -> basketA -> listOfInstruments
regionEntryB -> instrumentB -> basketB -> listOfInstruments
If the same instrument is in both lists, then as soon as you serialize
these entries and deserialize them, you'll have two separate instrument
instances.
One thing you can do is to store instrument ids in your basket instead of
actual instruments, and then lookup the instrument from the region based on
its id. This would save in serialization speed and use less heap in since
you would only be storing and replicating ids rather than entire
instruments from client to server and from peer to peer. The region lookup
could be done in fromData if you're using DataSerializable, or just in a
method call to the instrument to get its basket.
Serializing an entire instrument every time you add or remove an instrument
from its basket will probably be expensive though. Another thing you could
do is to have a separate basket region that stores the basket instruments
for an instrument. You'd probably just want to store the ids of the
instruments rather than the instruments. I don't know how big that list can
be or how often it is updated, but you could store one entry per instrument
containing the listOfInstruments or an entry per basket instrument. The
difference would be serializing an entire list whenever you add or delete
from it -vs- serializing an entry when it is added or deleted. Lookup would
be a get in the list case and a query in the per entry case. In either
case, you'd get a list of instrument ids, then you could do a getAll or
function to get the actual instruments.
Thanks,
Barry Oglesby
On Thu, Aug 4, 2016 at 8:34 PM, Dharam Thacker <dharamthacke...@gmail.com>
wrote:
> OK so it means it follows same contract as per java hashcode equals where
> in case hashcode and equality stays it will always refer to same object
> when newly created provided their pdx serializaion binary remains same.
>
> I asked as I am going to store complex object graph which internally may
> refer same instruments within same region.
>
> Please correct me or guide me if there is anything else as well I should
> take care of.
>
> Thanks,
> Dharam
> On 4 Aug 2016 23:17, "Michael Stolz" <mst...@pivotal.io> wrote:
>
>> If the referenced instruments have the same key they will just behave as
>> updates to the same entry. You will not get duplicates.
>>
>> --
>> Mike Stolz
>> Principal Engineer, GemFire Product Manager
>> Mobile: 631-835-4771
>>
>> On Thu, Aug 4, 2016 at 6:53 AM, Dharam Thacker <dharamthacke...@gmail.com
>> > wrote:
>>
>>> Hi All,
>>>
>>> I am bit new to this.
>>>
>>> Could some one help me to understand region storage? I have following
>>> Instrument instance which internally refers to many Instrument instances
>>> via Basket.
>>>
>>> There is 1 Instrument region which contains all instruments. Would there
>>> be duplicate instrument objects created within Basket even though similar
>>> Instrument object exists within region (By hashcode/equals - Reference
>>> point of view)
>>>
>>> Class Instrument{
>>> Basket backet;h
>>> }
>>>
>>> Class Backet{
>>> List<Constituent> constituents;
>>> }
>>>
>>> Class Constituent {
>>> List<Instrument> instruments;
>>> }
>>>
>>>
>>> Thanks,
>>> - Dharam Thacker
>>>
>>
>>
