Lets say I have a class of customer data. This class is designed to be used as a "valueobject" class (ie. as data to be passed around as parameters)
pseudo-code:
CLASS customer:
DEF PUBLIC PROPERTY Name AS CHAR.
DEF PUBLIC PROPERTY LastOrderDate AS DATE.
[etc]
[etc]
END CLASS.
So, I have my library methods to create and populate such a class and pass it around from method to method.
Now, what would you do if a new order record got added to the client from another session ? Obviously we can publish a message (hello Greg!) to inform all other sessions that a new order has been placed, and the LastOrderDate property for this customer is now updated.
What I am interested in is that what do we do with the objects that are already instantiated (and therefore now have out-of-date information) ?
Should they subscribe to the appropriate events, and get re-populated ? Does that not break the "data only, no functionality" rule of Value Objects ?
The issue here is really no different than reading data into a temp-table or local variables. If you read data and some time passes before it is used, the data may no longer reflect the state of the database. The answer about what to do about it is, that depends. I.e., if you are doing something where that possible update doesn't matter, then don't worry. If you are doing something where it does matter, then you should always obtain the data in a timely fashion.
I have worked with non-ABL systems in which one would have something like a customer data source object which provided all customer data for all consumers and through which all updates would flow. In such an environment, a consumer could request data and optionally subscribe to change events for that customer. If the data source detected an update ... which, of course, impliess that all updates flow through it, it could then publish an event to all subscribers to refresh their copy. I haven't been able to think of any practical way to do this in a pure OpenEdge environment, but one could accomplish it in an ESB environment by having a Customer Data Source service. But, the price of doing so would be creating a possible choke point, since such a service cannot be parallelized (at least not until 11.0) and slowing down access to customer data in general since every fetch of customer data would be across the bus, not direct from a DB.
So, I think the main lesson here is timely fetching of data.
BTW, not to nitpick, but objects like parameter objects or message objects are expected to be extremely short lived, last only from the time that the source builds them until they are consumed by the recipient. The recipient should then be moving the data values to its own properties and destroying the value object. So, your real issue should be with a long lived object which has previously received such a parameter object. And why, one might wonder, is such an object hanging around long enough for the question to arise ... any more so than it would with parallel situations in non-OO environments.
One might also note that there is a role here for before image handling, which should be part of your data access layer. The persistence process is going to detect that the last order date in the before image is not the same as the current state of the database and you can choose to handle that as you see fit in the context.
In terms of the nitpick, most of these "parameter" objects are, indeed, short-lived. I don't understand the comment, however, about " The recipient should then be moving the data values to its own properties". All this does is move the problem along to to the recipient.
The not-quite-a-nitpick was orthogonal to your question. The issues of timeliness and concurrency are there regardless of who is the current holder of the information. I was just encouraging you to discard the message as soon as the message had served its purpose of communication rather than hanging on to it.