I understand that in the new 2.0 API, you will expose InvocationContext for the user as a thread local variable. Right now, I can see that Option can be set there such that all subsquent code will be affected by that Option. PojoCache 2.0 also has the need to use an Option to set a BR region. I am debating now to either 1) to be consistent with Cache/Node such that I also use a similar InvocationContext to set it explictly, or 2) overload my APIs (3 of them) with an Option parameter, e.g., cache.attach(id, pojo, option). I am inclining to go with the first one. However, after thinking it over, I am not that comfortable with it yet. Manik, I hope you can convince me. :-) The good thing about setting Option in a threadlocal variable is that there is not extra APIs so the interface is cleaner. However, IMO, InvocationContext should belong to the SPI per se, not the API. That is, user should not see it. Af far as I can see, currently InvocationContext only carries Option that is interested to a caller. In addition, a user will need to: {{{ Option option = new Option(); InvocationContext.getCurrent().setOption(option); cache.put(fqn, key, value); ... }}} Nothing wrong but I just think it is relatively prone to errors. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3961521#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...