[infinispan-dev] [ISPN-31]JPA based cache store

[Jason T. Greene]

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 :)

--
Jason T. Greene
JBoss, a division of Red Hat