[jbosscache-dev] migrating data stored in 1.x format to VAM format

Manik Surtani manik at jboss.org
Thu Feb 8 08:28:21 EST 2007 

On 5 Feb 2007, at 19:57, Galder Zamarreno wrote:

> Quick (but a bit lengthy :( ) update on this:
>
> - I've created a new Marshaller called Legacy1xMarshaller (anyone's  
> got a better name?) which extends o.j.c.m.AsbtractMarshaller that  
> would do the job of marshalling stuff in the 1.x fashion. This is  
> to be used by JDBCCacheLoader and FileCacheLoader if configured to  
> use 1.x marshalling. This has the benefit that the code in these  
> cache loaders only have to do getMarshaller().whatever... , making  
> it very simple to switch from VAM to Legacy Marshaller.

I presume the VAM would transparently flip between marshallers, based  
on the version short at the head of the stream?

>
> - In order to do this, I need to add a new method to  
> o.j.c.m.Marshaller called objectToStream(OutputStream). The reason  
> for doing is so that FileCacheLoader just needs to call  
> getMarshaller().objectToStream() when it's trying to store data.  
> This will avoid having an if statement in storeAttributes()  
> checking which Marshaller is used, and calling objectToObjectStream  
> with the corresponding ObjectOutpuStream.

Again, isn't this already in the VAM?

>
> - The decision maker for which Marshaller to use is to be done in  
> AbstractCacheLoader which will store the Marshaller used by  
> CacheLoader. getMarshaller() would decide upon configuration, which  
> Marshaller to use, whether the default cache.getMarshaller() which  
> is VAM or the legacy one, making it quite clean to switch from to  
> another.

Look at the VAM in the 1.4.x tree - it deals with "legacy support" to  
deal with JBC 1.2.x and 1.3.x for RPC calls.  (removed in 2.x since  
the legacy support was no longer needed).  Could easily be re- 
introduced if needed to supportr legacy marshalling for CLs.

>
> - Configuration wise, I created  
> Legacy1xMarshallingCacheLoaderConfig (I couldn't come up with a  
> better name!) which extends IndividualCacheLoaderConfig.  
> JDBCCacheLoaderConfig and FileCacheLoaderConfig will extend  
> Legacy1xMarshallingCacheLoaderConfig instead.

Could drop the 1x in the name, I suppose?  :-)

>
> - Inside Legacy1xMarshallingCacheLoaderConfig, I search for  
> cache.loader.marshalling.1.x (name again!) boolean property in the  
> <properties> section. If true, it uses legacy marshalling, and if  
> false, which is default value, VAM.
>
> - I have extended CacheLoaderTestsBase to create  
> FileCacheLoaderLegacyMarshallingTest which tests the  
> FileCacheLoader with legacy marshalling. I'll be doing the same for  
> JDBCCacheLoader.
>
> - Finally and one of the most important aspects, previous  
> marhalling relies on these classes:
>
> org.jboss.invocation.MarshalledValue;
> org.jboss.invocation.MarshalledValueInputStream;
>
> Which used to be located in jboss-minimal.jar in 1.x. There's v  
> similar classes in AOP but not the same, so I'm gonna be creating a  
> legacy directory in lib with this library. To avoid compile time  
> dependency, Legacy1xMarshaller will be instantiated via reflection,  
> so only people who actually use this will need this library. The  
> library has no conflicts with existing 2.x libraries.

Look at the jboss-common-core jar and particularly JBCOMMON-8 in JIRA.

>
> The last problem is that these two classes access  
> org.jboss.logging.Logger that used to be in jboss-common.jar. Now  
> this jar certainly classes with jboss-common-core.jar in 2.x, so  
> what's I've done is get jboss-logging-spi.jar 2.0.2.GA and put it  
> in the legacy directory.
>
> So, we end up having two legacy libraries in lib/legacy but they're  
> only needed at runtime if using 1.x marhalling. I guess it's the  
> price to pay to make customer's life a bit easier.
>

Trying to avoid a legacy jar dir ... like I said, see if the MV and  
MVIS can be in jboss-common-core (without JBoss Logging deps!)

> The other alternative would be for 1.x marshaller not to use this  
> org.jboss.invocation.* classes and just write to Object streams but  
> I think these classes have an impact in the format of the  
> marshalled data. Brian, do you know a bit more about the role of  
> these classes?
>
> A bit more complicated than initially expected but I can't see any  
> easier way of providing backwards compatibility. Hopefully we  
> should be able to phase it out asap, 3.x? :)
>
> What this has shown as well is how different CacheLoaders  
> marshalled things in a slightly different way which makes having a  
> common framework for this even more necessary, i.e. VAM. :D
>
> Hope you're not snoring by now ;)
>
> If you have better ideas for the naming I used, speak up :)
>
> Galder Zamarreño
> Sr. Software Maintenance Engineer
> JBoss, a division of Red Hat
>
> -----Original Message-----
> From: jbosscache-dev-bounces at lists.jboss.org [mailto:jbosscache-dev- 
> bounces at lists.jboss.org] On Behalf Of Galder Zamarreno
> Sent: 31 January 2007 01:01
> To: Manik Surtani
> Cc: jbosscache-dev at lists.jboss.org
> Subject: RE: [jbosscache-dev] migrating data stored in 1.x format  
> to VAM format
>
> +1, VAM should be the default.
>
> Only people who are resilient to change their existing stores to  
> VAM should use the 1.x option, which would need explicitly definition.
>
> Galder Zamarreño
> Sr. Software Maintenance Engineer
> JBoss, a division of Red Hat
>
>
> -----Original Message-----
> From: Manik Surtani [mailto:manik at jboss.org]
> Sent: 30 January 2007 22:55
> To: Galder Zamarreno
> Cc: jbosscache-dev at lists.jboss.org
> Subject: Re: [jbosscache-dev] migrating data stored in 1.x format  
> to VAM format
>
> I see what you mean, although I would like the default to be to use
> the VAM.
>
> --
> Manik Surtani
>
> Lead, JBoss Cache
> JBoss, a division of Red Hat
>
> Email: manik at jboss.org
> Telephone: +44 7786 702 706
> MSN: manik at surtani.org
> Yahoo/AIM/Skype: maniksurtani
>
>
>
> On 30 Jan 2007, at 20:45, Galder Zamarreno wrote:
>
>> Actually, the more I think about this, the less I like the idea of
>> switching the marshalling from 1.x to 2.x at the CacheLoaders
>> level, or at least forcing them to do so.
>>
>> Customers that want to use JBossCache 2.x might be reluctant to
>> migrate their data from one format to the other. I can see how an
>> existing customer might think this is a proper pain in the ass,
>> independent of the benefits, and might reduce adoption among them.
>>
>> We want to remove barriers upgrading, but at the same time, we want
>> new customer to use new marshalling, so I'd actually implement the
>> possibility to use 1.x marshalling which is plan java serialization
>> at the CacheLoader level. This could easily achieved adding a
>> property to the <properties> section.
>>
>> Just note that this does not apply to the marshalling done at
>> replication level as there's no hard data that needs migrating.
>>
>> Galder Zamarreño
>> Sr. Software Maintenance Engineer
>> JBoss, a division of Red Hat
>>
>> -----Original Message-----
>> From: jbosscache-dev-bounces at lists.jboss.org [mailto:jbosscache-dev-
>> bounces at lists.jboss.org] On Behalf Of Galder Zamarreno
>> Sent: 25 January 2007 13:07
>> To: jbosscache-dev at lists.jboss.org
>> Subject: [jbosscache-dev] migrating data stored in 1.x format to
>> VAM format
>>
>> Hi all,
>>
>> I'm deferring http://jira.jboss.com/jira/browse/JBCACHE-879 to
>> BETA2 because I still need to write this: http://jira.jboss.com/
>> jira/browse/JBCACHE-882
>>
>> The reason I'm deferring it is because I can't see a
>> straightforward way of doing such thing right now. Ideally, you
>> should be able run a 1.x version (cache1) and a 2.x version
>> (cache2) of JBC in the same VM so that you can do a loop of
>> cache1.get() and call cache2.put(). However, I have doubts that
>> that this approach will be free of class loading issues. What do
>> you think?
>>
>> I was wondering whether Region based could help here, but I can't
>> see right now how this could be done.
>>
>> Something I had in mind is having the capability of to start a
>> cache with either 1.x marshalling or VAM marshalling, but oriented
>> at being used only at the cache loader level. It wouldn't make much
>> sense for replication because there's no hard data there.
>>
>>
>> I thought that you could start two instances of cache 2.x, first
>> with 1.x. marshalling and the other one with VAM both pointing to
>> different JDBCCacheLoader stores. You could then get from the first
>> using normal mmarshalling and put in the second one which has VAM
>> marshalling active, what do you think?
>>
>> If you like the approach, I should be have it ready by BETA2.
>>
>> This last approach looks simpler to me, what do you think?
>>
>> Galder Zamarreño
>> Sr. Software Maintenance Engineer
>> JBoss, a division of Red Hat
>>
>>
>>
>> _______________________________________________
>> jbosscache-dev mailing list
>> jbosscache-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jbosscache-dev
>>
>> _______________________________________________
>> jbosscache-dev mailing list
>> jbosscache-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jbosscache-dev
>
>
>
> _______________________________________________
> jbosscache-dev mailing list
> jbosscache-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jbosscache-dev

More information about the jbosscache-dev mailing list