4 Replies Latest reply on Jun 28, 2006 10:46 AM by Jörn Eyrich

    PojoCache: why are final/static fields not replicated?

    Jörn Eyrich Newbie

      Hi,

      can anybody give me a rationale for not replicating final and static fields in PojoCache? I can think of some scenarios where there could be problems, but I'm not sure why it is not even offered as an option.

      I couldn't find an explanation in the documentation, on the wiki, or in the forums.

      Anyone care to enlighten me? I don't want to complain, just understand.

      Thanks very much,
      Joern

        • 1. Re: PojoCache: why are final/static fields not replicated?
          Bela Ban Master

          final fields cannot be modified, so why replicate them ?
          However, static fields *should* probably be replicated, what is the current behavior ? Ben, Brian ?

          • 2. Re: PojoCache: why are final/static fields not replicated?
            Jörn Eyrich Newbie

            Thanks for the quick answer.

            Concerning final, I see that it makes no sense replicating final fields that point to immutable objects (e.g. Strings). But when the referenced object is mutable I might want to replicate changes to it, too.

            Objects are mapped into the cache by reachability, but objects referenced by final fields aren't, so I have to do this manually.

            I think I have seen that when I do a putObject(), fields containing Collections are replaced with AOP Proxies. This of course would be a problem with a final field; but why disallow it for other kinds of objects?

            • 3. Re: PojoCache: why are final/static fields not replicated?
              Ben Wang Master

              It is stated in the documentaiton that currently neither final, transient, or static fields are replicated.

              To replicate static is really case dependent since it it a global variable. Question is then how do we store it internally if there are multiple POJOs stored in the cache? And this has implication such as region, etc.

              As for final, I can make it configurable if there are enough use cases such that it can be treated as mutable.

              • 4. Re: PojoCache: why are final/static fields not replicated?
                Jörn Eyrich Newbie

                Oh yes, the documentation makes it clear that those are not replicated; I was just curious about the reasoning behind that (a customer asked and I couldn't come up with entirely satisfactory answers).

                For the static case, I agree that this shouldn't be the default. But as with final, in simple cases it could be desirable to have the option. As for how to store it, I think most people would expect that multiple POJOs shared the same static instance just as it would be without the cache. In my thinking, this wouldn't have to be handled differently from the case where many POJOs reference the same object non-statically. Are regions used for more than eviction? If not, I think the referencing POJOs could just be evicted as usual, and the sole static object instance could be kept somewhere else, separate from the regions containing the referencing POJOs (__internal__:<fully qualified class name>?).

                But I'm just asking. "Nobody has needed it yet and it would need some more thought, so we are working on more pressing issues. If you think you need it, request the feature in JIRA and if enough people want it, we'll look into it" would be a perfectly satisfying answer for me. I just wanted to know if there are known reasons that make it (practically) impossible to support this.

                Thanks for your comments.