On 23 Jul 2009, at 15:34, Alejandro Montenegro wrote: > Hi guys, > some thought about this issue. Mainly there are two option for the > implementation: > > 1- Objects stored in cache are by themselves Entites (marked with an > @Entity) > > 2- Create a kind of wrapper Entity for non-entities objects > > [1] Are more straight forward and should perform better, but are > restricted to Enities > [2] Are more complex to develop, as have to figure out a good > structure fot the wrapper, but satifies a lot of more use cases. I think we can offer both. The cache store could maintain two hash sets - known @Entity types and known types that are not entities. These would be populated lazily by testing for the @Entity annotation every time a new user type is encountered. These sets could then be consulted when deciding how to persist an object: either treat it as a an @Entity or wrap it in an EntityContainer. The structure of an EntityContainer should be pretty straightforward, where it would contain two fields: a byte[] to hold the serialized form of the object being stored, and an ID which could be an auto incrementing key.

Jason T. Greene wrote: > Manik Surtani wrote: >> On 23 Jul 2009, at 15:34, Alejandro Montenegro wrote: >> >>> Hi guys, >>> some thought about this issue. Mainly there are two option for >>> the implementation: >>> >>> 1- Objects stored in cache are by themselves Entites (marked with >>> an @Entity) >>> >>> 2- Create a kind of wrapper Entity for non-entities objects >>> >>> [1] Are more straight forward and should perform better, but are >>> restricted to Enities >>> [2] Are more complex to develop, as have to figure out a good >>> structure fot the wrapper, but satifies a lot of more use cases. >> >> I think we can offer both. The cache store could maintain two >> hash sets - known @Entity types and known types that are not >> entities. These would be populated lazily by testing for the >> @Entity annotation every time a new user type is encountered. >> These sets could then be consulted when deciding how to persist >> an object: either treat it as a an @Entity or wrap it in an >> EntityContainer. >> >> The structure of an EntityContainer should be pretty >> straightforward, where it would contain two fields: a byte[] to >> hold the serialized form of the object being stored, and an ID >> which could be an auto incrementing key. > You don't want a byte array because then you can't compare fields. > I don't think there really is a big different between @Entity or > not @Entity in a infinispan implementation. In both cases you need > to reflectively discover the structure of the object, discover > references, and store the primitive and serialiable fields that > make up the object. > If EJB3 SFSB replication is rewritten to use this, the objects > definitely will not be @Entity :) OOPS I just realized this is about a JPA cache store, not the JPA- like POJO API Sorry! :)