3 Replies Latest reply on Apr 4, 2006 9:37 PM by Ben Wang

    Refactoring ejb3 SFSB passivation

    Ben Wang Master

      I am proposing to refactor the current passivation mechanism in ejb3 SFSB. The motivations are:

      1. Leverage the passivation feature that has been in release JBossCache 1.2.4. It makes the whole code base easier to maintain in the future. In addition, it can support different cacheloaders (e.g., file, jdbc, etc.)

      2. To support the fine-grained SFSB implementation. Fine-grained SFSB needs to treat passivation as an aspect of the underlying cache rather than part of the bean cache.

      3. To remove of some usage of deprecated JBossCache API, e.g., get(fqn), and also some eviction policy apis have been also deprecated. This is a good time to do it.

      Overall the refcatoring should be straightforward, IMO, unless there is some overlooking issues. Here are couple of minor issues and differences:

      1. This requires JBossCache 1.3. Release 1.3 should be out this week. This should be no problem in jboss-head. But if we need to backport to 4.0, we will need to make sure 1.3 is used there as well. Since 4.0.4CR2 is almost out, the remaining issue is if we need to backport any ejb3 code before GA. If needed, I can help out on this front. Otherwise, 4.0.5 shouldn't be an issue.

      2. Previously, cache loader is supported as file based and specifying the file location programmatically. Now we will specify cache loader from ejb3-clustered-sfsbcache-serivce.xml and paramterize the the fiel location. User can specify a different passivation/cache loader mechanism, if chooses.