[infinispan-dev] Warning about JBMAR 1.2 upgrade

[Manik Surtani]

On 5 Jun 2009, at 14:48, Galder Zamarreno wrote:

>
>
> Manik Surtani wrote:
>> On 4 Jun 2009, at 16:49, Galder Zamarreno wrote:
>>> Hi,
>>>
>>> I've upgraded trunk to JBMAR 1.2.0.CR1. There's a couple of tests  
>>> failing due to https://jira.jboss.org/jira/browse/JBMAR-59 which  
>>> is already fixed and will be included in 1.2.0.CR2. I'll upgrade  
>>> to that asap.
>>>
>>> Failing tests due to these issue are:
>>>
>>> JBossMarshallerTest.testExceptionResponse
>>> ReplicationExceptionTest.testLockAcquisitionTimeout
>>>
>>>
>>> Finally, with 1.2 upgrade, payload of all objects marshalled with  
>>> JBMAR are smaller than with the old marshaller. Bela will like  
>>> this! :)
>> Great.  I also notice that you have completed the VAM fix.  This is  
>> good news too, to versioning bits will be minimised on the stream.   
>> Again, leads to faster execution and smaller payloads.
>
> Yeah, I had analysed the objectToStream calls made within for loops  
> this from were coming from trying to apply persistent state, so as  
> long as versioning is written done when the stream is started,  
> that's enough to find out what version to use to marshall/unmarshall  
> the entire state stream.
>
>
> I have further ideas though: For example, do we forsee different  
> Infinispan instances (each diff version) using the same database  
> table in case of a JDBCCacheLoader? Also, do we forsee the same  
> happening with a FileCacheLoader in terms of location?

Hmm.  I'm guessing the answer is no - unless it is a shared cache  
store.  But then switching on whether a cache store is shared or not  
will prevent people reconfiguring a cache store from being shared to  
not, or vice versa.

> If yes, we still need individual entries to contain version  
> information. Otherwise, we could even reduce version information  
> writing to once in the table, or once for the entire FileCacheLoader  
> location.

I don't think individual entries need this, I think each bucket  
probably does.

>
>
>> Nice one!
>> Cheers
>> -- 
>> Manik Surtani
>> manik at jboss.org
>> Lead, Infinispan
>> Lead, JBoss Cache
>> http://www.infinispan.org
>> http://www.jbosscache.org
>
> -- 
> Galder Zamarreño
> Sr. Software Maintenance Engineer
> JBoss, a division of Red Hat

--
Manik Surtani
manik at jboss.org
Lead, Infinispan
Lead, JBoss Cache
http://www.infinispan.org
http://www.jbosscache.org