We've been building up a distributed data store that has a BDB at each leaf node. There are a few layers that our objects go through, and up until now we've been able to use our Entity objects directly throughout the code. They get serialized by RMI and make their way to our BDB nodes and get persisted by the DPL.
But now we have a situation where we have a field that we want serialized (non-transient) so that it makes its way all the way through our system, but then not persistent when it reaches the DPL. (We also have a search index at each leaf, and this bit of data includes some instructions for the search engine.)
The best solution (from my perspective!) would be simply to have an @NonPersistent annotation to make the DPL ignore a particular field. Lacking that, I came up with a couple options, neither of which I like. First, I could add a wrapper object that isn't an Entity class that contains my non-persistent data. I don't really like this idea, but it could work (makes all my objects a little larger and they get serialized a LOT). Second, I could modify readObject and writeObject to manually throw in the transient fields that I wanted to keep around. I don't really like that either (for different reasons), but it also could work.
Any other thoughts? Is there anything I'm missing that would allow me to do this easily?
I think the addition of @NonPersistent is a reasonable request and probably the only good solution. One of the primary goals of the DPL is to be able to persist objects that are used in other ways -- RMI is a good example. In other words, the DPL intends to be a pure POJO persistence solution. However, we didn't consider the case of a field that is persistent with respect to RMI but not the DPL, or vice-versa. So I think solving this is important.
Let us spend some time on that and we'll see if we can get this into a 3.3 dot release. This is a fairly simply addition, but we'll need to also consider the reverse situation -- a field that is persistent WRT the DPL but not RMI. In other words, we may need both @Persistent and @NonPersistent to apply to a field to override the default rules. And we'll need to encapsulate this information in the EntityModel abstraction so that it can be used without annotations.
In the meantime, I suggest using one of the workarounds you mentioned, or perhaps even modifying the DPL source code in a way that works for you, temporarily.. If you choose the latter, note that there is only one place where field persistence is determined, which is in the getInstanceFields method of this class:
Thanks for the response. For the time being, I've modified writeObject and readObject to include the data that I want. This seems to work reasonable well. I'll be very happy to change it to use an @NonPersistent annotation if it works out. And you're absolutely right -- somebody might want to persist a transient member (although I would suspect that this is the less frequent case).