Welcome to the new Gigaspaces XAP forum. To recover your account, please follow these instructions.

Ask Your Question
0

reference to a non-space POJO in a space property

My application has a mixture of objects that are stored in the space and objects that are not. What are the consequences of storing a reference to a POJO that isn't stored in the space in a property of an object that is stored in the space?

This is the kind of setup I'm talking about:

class InSpace // SpaceClass stored in local space. { private NonSpace m_ns; // class NonSpace - a POJO that is not a SpaceClass, not stored in the space at all.

@SpaceProperty
NonSpace getNS() { return m_ns; }
void setNS(NonSpace ns) {m_ns = ns; }

}

When an InSpace instance is written to the local space, is a whole copy of the NonSpace referred to by m_ns written along with it? Or is it just a reference? I want to know largely because I might have many InSpace instances that all refer to the same NonSpace instance. If they are all carrying along full copies of that instance rather than just a reference, it would be wildly inefficient.

I can see other ways to handle this, namely have InSpace carry some kind of id property that can be used to look up a NonSpace instance through some other API... I want to know if I have to go through the trouble of doing that or if I can just stick with the easier direct reference.

Let me add (if it's not obvious) that I'm talking about writing and reading the InSpace instances from a local space partition which is guaranteed to be located in the same memory space as the NonSpace instance. Of course I would not expect a reference to a non-space object to carry over if it goes into a different partition!

Thanks, Ryan

{quote}This thread was imported from the previous forum. For your reference, the original is [available here|http://forum.openspaces.org/thread.jspa?threadID=2011]{quote}

asked 2008-01-09 19:49:45 -0600

ryryguy gravatar image

updated 2013-08-08 09:52:00 -0600

jaissefsfex gravatar image
edit retag flag offensive close merge delete

1 Answer

Sort by ยป oldest newest most voted
0

I'm not sure what you are trying to do , but why you can't use transient field (or don't map it) for the inner/nested object you don't want to store within the space?

If you won't do that the parent object will store also its inner/nested object within the space.
In any case - We do not break these into 2 separate entries within the space.

Shay

answered 2008-01-10 06:10:19 -0600

shay hassidim gravatar image
edit flag offensive delete link more

Comments

Thanks Shay.

The thing is that if I don't map the field containing the nested object, then when I retrieve the object from the space, that field will be zeroed out. Basically for the outer object, I'd be writing it into the space and not keeping a direct reference to it. Meanwhile, the nested inner object +would+ still be referenced by something outside the space, like a static container in a service. I don't need the outer object to manage the lifetime of the inner object, I just need to know which one it is associated with. And when I put it that way, it certainly does seem more natural for the outer object to keep some kind of id rather than a reference to the object itself.

In fact, if the outer object entry contains the inner object as a binary blob, then if I changed the instance of the inner object that is kept in that static container, those changes would not be reflected when I read in the outer object - it would reconstitute its inner object from that unchanged blob, right? Basically it is keeping a copy of the inner object in its entry.

Ok, that is what I needed to know. Thanks!

-Ryan

PS - just for my general knowledge, what if the inner object +was+ a SpaceClass that is written into the space on its own? Would the outer object still create a binary blob out of that nested object for its own entry?

ryryguy gravatar image ryryguy  ( 2008-01-10 12:47:23 -0600 )edit

In the meantime I found the documentation about Entries which pretty much spells out how all this works. So I'm good to go... thanks again for the help.

ryryguy gravatar image ryryguy  ( 2008-01-10 20:06:28 -0600 )edit

I do not find logical reason for a space object to store a static object or shared object across many other objects that are not stored within the space. Can you explain the use case? The space is your shared objects repository.

Any case , the following link will provide you more details about how the space handles native/primitive objects and how it handles user defined classes/collections as space Class fields when performing remote operations (client-space , space-space): http://www.gigaspaces.com/wiki/displa...

Here are few guidelines: - Non native field serialization impacts remote space operations and replication time very much. Since each operation by default serialize and de-serialize this object, you should be careful with this object structure. Advanced implementations serialize and de-serialize this field on-demand (aka payload lazy serialization pattern). In the future we will provide this capability out of the box. For now you can get a blue-print of this pattern from our PS team. - By default, any inner object is serialized and is not introduced to the space as separate space entry. - We do not recommend having inner objects as searchable objects, but have all the fields you have to query as part of the parent Entry Class fields as indexed fields. - When the Space running in persistent mode(indexed file/RDBMS) space class inner objects fields are stored as one blob. We have a special optimization for Oracle that split this blob into several blobs. - If the inner object annotated with @SpaceClass, the outer object will still create a binary blob out of that nested object for its own entry. - When running in embedded mode (by default with Native serialization mode) , we do not serialize non native/primitive objects. The embedded space stores references to these objects. Please do not rely too much on this fact when having multiple objects referencing the same object , since after replication these references serialized and de-serialized. Light , Full and compressed serialization mode does serialize the object when running in embedded mode. This impacts the performance. - Entries/POJO relationship can be constructed via UID operations. See: http://www.gigaspaces.com/wiki/displa... . Having another id field to allow you to build relationship between objects is also valid approach.

If you need additional help with this delicate issue please drop me a line at: shay at gigaspaces dot com

Shay

shay hassidim gravatar image shay hassidim  ( 2008-01-12 09:59:12 -0600 )edit

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools

1 follower

Stats

Asked: 2008-01-09 19:49:45 -0600

Seen: 95 times

Last updated: Jan 10 '08