Long time no see! How are you doing? Is the new job going well?

You are correct — the example given in the post is amenable to all of its fields being final (although it makes little difference since they are private and there are no setters). The main reason I didn’t make them final here is that the example is adapted from the code we really developed and that was slightly different, making final fields unusable.

The “prototype” scope might be a solution depending on how your application was built. The main thing to remember is that prototype scope means that a bean is instantiated every time it is referenced FROM THE SPRING CONTEXT, not every time it is used from client code. That is, every time a bean is injected, a new object will be created for injection; but injected is injected so if some code USES an injected (prototype) bean twice, that client code will not magically be given a new bean object between Java method calls (unless the client code retrieves the bean from the context itself before each method call on that bean). Particularly relevant here is that a prototype bean injected into a singleton bean will not be replaced in the lifetime of the singleton bean. In a typical web or webservice app you would not have the entire bean tree rebuilt for each request (you would make the middle tier service beans singletons), so prototype scope will not help. Unless you make EVERY bean in the middle tier (or at least every bean involved with a certain request-response) prototype scoped, but then you have to consider carefully what the impact will be on the performance of the application. Or you can use method injection to inject a lookup of the prototype bean into the unmodified (singleton) service code you already had, but that probably isn’t the quick fix I was looking for in this article.

Note that you can possibly fix the entire situation in the Spring context definition in a web application by using the request scope rather than the prototype scope (this has a bean recreated each time an HTTP request is received). Your Spring config will become a bit more fiddly though, since you’ll need an AOP scope proxy to make sure that the request-scoped bean is correctly re-injected (or looked up) in the existing service code. I have to note though that I’m not completely sure of how thread-safe this solution is. Plus, I have a hunch that if your code is amenable to this solution, you were probably already clever enough as a developer to avoid the problem I was trying to fix.

Avoiding objects with (changing) state is usually a lot more efficient then having objects with modifiable state, so I think your listed solution sounds good.

I suggest adding final to all fields in ServiceMemento, do indicate the state of the object should not be changed.

Would a quick alternative solution not be changing the scope of the bean in the spring configuration?
By changing the scope to prototype (http://static.springframework.org/spring/docs/2.0.x/reference/beans.html#beans-factory-scopes-prototype) the object should be instantiated each time it’s referenced.