Reusing options in PojoCache

[brian.stansberry]

Jason,

Just got bit by a bad practice, and I see PojoCache is doing the same thing (at least in 1.4.1.x), so wanted to give you a heads up.

The bad practice is trying to reuse an Option -- i.e. create and configure an Option, cache a ref to that instance and then pass that instance to the cache whenever you make an invocation w/ that semantic.

PojoCache does this in InternalDelegate with the gravitateOption_ and skipLockOption_ fields.

This is a problem because JBC makes no guarantees that it won't change the internal state of an Option during the course of an invocation. Manik and I had a discussion about this a couple weeks back, but I can't find it to give you a link. JBCACHE-1209 is an example of a subtle issue where JBC was changing the internal state of an option the AS code was trying to reuse.

[jason.greene]

Thanks for the heads up. I checked and 2.0 doesn't make this mistake. I will take a look at patching the 1.4 branch.

[brian.stansberry]

FYI, Manik's going to have to respin 1.4.1.SP6 due to JBCACHE-1209, so you might want to get the change in the respin.

[mircea.markus]

if we do not want the users to reuse the option, wouldn t it be a good idea to enforce this through a runtime exception (if possible)? Perhaps we can do this when the user changes the option after being used (an Option method to throw an exception). Or perhaps when the option is passed to the cache

[manik]

I guess the InvocationContextInterceptor could mark all options as used on the way out, so that it barfs if it is reused/passed back in without being reset(). Does cause a problem with nested calls though.

[brian.stansberry]

Perhaps clone the Option in InvocationContext.setOptionOverride()?

(Above is only a suggestion if "document the issue to tell people not to do this" is consider insufficient.)