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

[Jason T. Greene]

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

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