On 4 February 2013 11:10, Dawid Loubser <[email protected]> wrote: > Hi all, > > I have a bunch of entries in a JavaSpace (representing long-running > process state, i.e. they exist for days or weeks), and these contain > some objects that were generated from XML (using JAXB). That vocabulary > has evolved (additions only) but now, of course, the computed > SerialVersionUIDs will be different. When I redeploy my workers that > have been built against the new API, they will surely fail when reading > the old entries. > > Any strategies as to how I can migrate the data in the space? I'm > running a persistent outrigger (snaplogstore). I was thinking of, in a > worker with an 'old' classpath, draining the space, and storing those > entries in some non-java representation on disk, and then in a worker > with the 'new' classpath, reading those entries and re-populating the > space.
Slightly more complicated but it's possible to have one worker do all this with some classloader magic. You basically load old and new definitions into separate classloaders with the old version being directly on the classpath, the other dynamically loaded from something not on the classpath. Then you can take the old easily and use reflection magic to populate a new and write it. One other challenge is that most JavaSpace implementations don't like mixed schemas do probably you're better to create a second space, write the migrated ones into that and then turn off the old one (or copy back to the old once you've cleared it down/re-built it). > > Migrating data in a space is surely something that must have caused > problems for somebody before, and I'd love to tackle this problem > drawing on some experience of others. > > regards, > Dawid >
