>
>In applications of type "set," users or even programs may set the values of
>objects in the database concurrently; without a "real time" notification of
>the changes, what one user does may overwrite what another user has just
>saved, and the program may not be able to tell that something has been
lost.
>Of course, even with such "real time" notifications, the client software
>needs to detect and handle situations in which someone else's changes get
>pushed to the user's terminal while the user is editing the modified field.
>
What you are talking about is the classic problem of keeping seperate
copies of the same thing. There are several ok solutions to the problem.
The solution I have worked with is to build your own applications
transaction
framework that adds some sort of tag (integer) to the object when you
check it out. If it's not the same when you try to commit it, you have a
transactional conflict. Of course, this is assumming that you are using
RDB (or similar technology) for persistance.
If you use an EJB server with built in persistance and support for
distributed
objects and distributed transactions, you won't need these things.
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
