DataNucleus JIRA is now in read-only mode. Raise any new issues in GitHub against the plugin that it applies to. DataNucleus JIRA will remain for the foreseeable future but will eventually be discontinued
Issue Details (XML | Word | Printable)

Type: Bug Bug
Status: Closed Closed
Resolution: Fixed
Priority: Major Major
Assignee: Andy Jefferson
Reporter: Andy Jefferson
Votes: 0
Watchers: 0

If you were logged in you would be able to see more operations.
DataNucleus Core

Put object with field of type StringBuffer into L2 cache references the same StringBuffer object in the cached object!

Created: 20/Jun/08 05:43 PM   Updated: 26/Apr/10 03:37 PM   Resolved: 21/Apr/10 09:32 AM
Component/s: Cache, Java Types
Affects Version/s: 1.0.0.m1, 1.0.0.m2
Fix Version/s: 2.1.0.m2

 Description  « Hide
When we have a class that has a StringBuffer field, and we have L2 caching turned on, when we create our object for L2 caching it copies the fields across to the L2 cacheable object. With StringBuffer there is no SCO wrapper and it copies the object rather than creating a new one with the same value. Means that when the L2 cached object is handed out it has the same StringBuffer reference!

Sort Order: Ascending order - Click to sort in descending order
Andy Jefferson added a comment - 23/Oct/08 11:46 AM
This is caused by the fact that StringBuffer is mutable, yet since it is final we cannot support it as SCO. Consequently we don't really support it, and it can hit people in this situation where they L2 cache it (as well as where they do any mutation of the underlying StringBuffer). Same thing applies to any other type that is really mutable yet is final so cant be handled

Andy Jefferson added a comment - 21/Apr/10 09:32 AM
SVN trunk fixes this for java.lang.StringBuffer fields