Good to know. Yes, a conflict handler function would definitely help. Until then, I'll be sure to be cognoscente of such situations and design accordingly.
In my example, it may not be wise to allow concurrent edits to a public object. Perhaps I can add a new property to allow locking of public entities while they are "checked out". Or perhaps I can store the entity id after a query, instead of holding onto the entity instance, and when I want to cast the vote, I'll load the entity by id and then perform the entity edit and queue the save after load. This way, if say, a player is staring at a Art instance for several hours and then decides to vote, all votes casted on that entity in that time won't get overwritten by the late save.
Another approach I had was to create a new entity called ArtVote in which users don't actually edit the Art entity directly. Instead, perhaps when the owner of the Art logs in, a query is made to search for all ArtVote instances that have been made since his last log in and then at that point they are consumed and the original Art entity instance can be saved by the owner. This approach was one that I was originally leaning towards since I could keep the Art instance access as READ instead of READ_WRITE. The only drawback is that other players would only be able to see an updated rating of an Art instance if they combined both the cached rating as well as queried for the pending ArtVote entities.
That's my story. Again, thanks for the prompt response