Win a copy of The Little Book of Impediments (e-book only) this week in the Agile and Other Processes forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Protecting cache in Data class from side effects

 
Matteo Palmieri
Greenhorn
Posts: 28
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi all,

I'm reviewing my Data access class for the URLyBird 1.2.1 and I've noticed something I'm not sure it is worth worrying about.
I have implemented record caching in the form of a map where the key is the record number, and the value is a String[] vector
representing the room's data.

The readRecord() simply returns the corresponding String[] instance object from the cache.
Similarly the updateRecord() and createRecord() change/add the String[] object into the cache.

As the Data class uses String[] objects created by the client and exposes String[] objects belonging to the cache it would be
much safer to make a deep copy of the array before it is returned to the client or put into cache, but this would be an
additional overhead. Otherwise I could rely on the assuption that the client does not change the array's content after having
been passed to/returned from the Data class.

What do you think would be the best approach ?
 
Roel De Nijs
Sheriff
Posts: 10662
144
AngularJS Chrome Eclipse IDE Hibernate Java jQuery MySQL Database Spring Tomcat Server
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Matteo,

I noticed exactly the same behavior when I was writing my test cases. I didn't make a deep copy, just changed the implementation of my Data class.

If you just adding String[] (passed as parameter) to my map (and replacing the old record representation), you can change your record cache without using update method:


If you get the String[] from my map (the record representation), then just iterates over the String[] (passed as a parameter) and finally update every field you can't update the record anymore without using update method:

That's for the update-method, the create-method you can "fix" in the same way (actually a create is an update on an empty record ;)) The read-method could be fixed with a deep copy, but I didn't do that

Because your are coding the application you can easily make the assumption "the client does not change the array's content after having
been passed to/returned from the Data class". And my business service doesn't use String[] but uses value objects, so that's a bit of protection, but not a complete one.

Kind regards,
Roel
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic