Hi, thanks again for your response,
for me the big issue here is that i have 2 separate problems, and either of them could require VC. But i don't want to have 2 version columns
I can't use the same column for both problems, because one is invisible to me, the Server does all the work, and doesn't allow me to poke around there.
Problem no1. I have the information i send to the CMP, when the CMP goes to store the data into the database he can be doing so from an old record (the web UI example). And i need to avoid this kind of errors.
First solution (i'm using) - Nefore he stores he has to check the version, to see if this is the correct version. If it is, then he can go ahead and store the thing.
This version column is managed by the server, i can touch it.
Now i have a second problem. The user has a DTO (or TO or Value Object) with the information matching the CMP, layed out on a nice web page. 5mts later (can be enough for someone else to make a change) he goes and send this to the SessionFacade.
And in here lies the problem, the SessionFacade has to findByPrimary key the CMP, and doing so he will get the brand new one in the DB.
So when he commit this information back to the CMP (that will search for problem no.1) everything will work fine.
The obvious solution, is a version checking, when the sessionFacade findByPrimaryKey the CMP, he could check the version in the CMP and the version in the DTO and if they were diferent then it's Exception time.
But as i said i don't have access to the version from problem 1
So i need one version for problem 1 and another for problem 2, and this doesn't strike me as the right solution
I think what you said "The read-write version causes notification events to be sent to the cache; the primary keys are part of that notification"
Can help me in problem 2, because instead of going to the database i can just the the CMP from the cache
About "You could do something as simple as a timeout on requests", it's hard, because data can be changed every second, or every hour, there would not be a right time for timeouts
For "...which means you could already be in a position to compare the current entity bean state to what was last shown to the user, and apply business logic to decide when they differ too much to allow the commit."
I think that problem 2 doesn't allow this solution, because the logic would have to be in a kind of Version Column, and in there lies the problem
Thank you for your help
If you could nudge me in the right direction i would appreciate it. I think
the problem is much clearer now
(Sorry for any english mistakes)