One further thought on this, the mapper jvm may be loading the jar and overwriting / throwing away all previous class descriptions from the previous map job, which will remove the statics and reinitialize. In this case, the singleton won’t work if it is in the job jar. What will work is putting the singleton in a global classpath (shared library not in the job jar).
On 3/6/09 12:46 PM, "Scott Carey" <[email protected]> wrote: The difference is that if the whole mapper class itself is being reloaded somehow (instantiated by reflection and then de-referenced and gc’d?) the static won’t work the way you expect. Not knowing how that works, and assuming that statics there don’t work, a singleton in another class may still work. The singleton class is certainly not being instantiated by reflection so (I believe) only a classloader closing will get rid of it. At least, its worth a try, since unlike the mapper class, you control how it is instantiated. So the two cases are not the same. On 3/6/09 12:13 AM, "Rasit OZDAS" <[email protected]> wrote: Owen, I tried this, it doesn't work. I doubt if static singleton method will work either, since it's much or less the same. Rasit 2009/3/2 Owen O'Malley <[email protected]> > > On Mar 2, 2009, at 3:03 AM, Tom White wrote: > > I believe the static singleton approach outlined by Scott will work >> since the map classes are in a single classloader (but I haven't >> actually tried this). >> > > Even easier, you should just be able to do it with static initialization in > the Mapper class. (I haven't tried it either... ) > > -- Owen > -- M. Raşit ÖZDAŞ
