RE: [jbosscache-dev] migrating data stored in 1.x format to VAM format
by Galder Zamarreno
+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@jboss.org]
Sent: 30 January 2007 22:55
To: Galder Zamarreno
Cc: jbosscache-dev(a)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(a)jboss.org
Telephone: +44 7786 702 706
MSN: manik(a)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(a)lists.jboss.org [mailto:jbosscache-dev-
> bounces(a)lists.jboss.org] On Behalf Of Galder Zamarreno
> Sent: 25 January 2007 13:07
> To: jbosscache-dev(a)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(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jbosscache-dev
>
> _______________________________________________
> jbosscache-dev mailing list
> jbosscache-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jbosscache-dev
17 years, 10 months
RE: [jbosscache-dev] migrating data stored in 1.x format to VAM format
by Galder Zamarreno
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(a)lists.jboss.org [mailto:jbosscache-dev-bounces@lists.jboss.org] On Behalf Of Galder Zamarreno
Sent: 25 January 2007 13:07
To: jbosscache-dev(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jbosscache-dev
17 years, 10 months
RE: [jbosscache-dev] Dependency on concurrent jar
by Vladimir Blagojevic
That's right. IIRC Bela said end of March for 2.5. It would be good to
test HEAD with both 2.4 and 2.5.
+1 to remove all traces of concurrent.jar dependency now.
> -----Original Message-----
> From: Manik Surtani [mailto:manik@jboss.org]
> Sent: Tuesday, January 30, 2007 1:41 PM
> To: Vladimir Blagojevic
> Cc: jbosscache-dev(a)lists.jboss.org
> Subject: Re: [jbosscache-dev] Dependency on concurrent jar
>
> In HEAD? We can't ship without it since JGroups still needs it.
> Until we're up to JGroups 2.5, we can't get rid of the jar.
> Unless we put a snapshot of JGroups 2.5 in HEAD.
>
> What's the ETA for JGroups 2.5 anyway, just wondering if we
> can release 2.0.0 with JG 2.5.
>
> +1 to removing any JBC deps on concurrent.jar though.
>
17 years, 10 months