Victor,
I agree to a certain extent that timestamp/versioning is a bit
simplistic. But the fact is - it works.
> I wouldn't what my user to get an exception when
> attempting to update an employee's first name because some other unrelated use case
>has
> concurrently modified their total vacation time or yearly salary. Would you? Many
> applications will need finder grained control than a single timestamp/version even
>in a
> highly normalized schema.
Well ... now we are getting scenario dependent. Aren't we?
How do you decide when to throw an exception and when not?
If your EJB vendor supports verified updates, the exception
would still be thrown i.e the update would fail. So since
these are application domain specific use cases - it is
difficult to apply certain rules (like optimistic concurreny)
to a specific subset of your application and a different set
of rules to other parts (unless you are going with BMP
and/or another persistence manager like Toplink). At least
this is not possible with CMP in most EJB 1.1 vendors as far
as I know and maybe the upcoming EJB 2.0 will change things.
What would be perfect would be some way to define which
beans are critical in your application - and apply specific
concurrency solutions to these beans only. So that might
solve your problem of "I want to be able to modify the
salary of an employee even if some other user/application
has modified other attributes" while allowing stricter rules
to be applied to other parts of your application doman.
That way, performance penalties are incurred only in cases
where data is critical and corruption/accidental overwrites
are unacceptable.
> I don't know how borland's "verified updates" handles the case where the entity bean
>has
> been passivated (i.e. returned to the pool) before the client returns the modified
>data.
> But a similar scheme which tracks modifications to every attribute during the entire
> logical transaction is needed for many applications.
I am just a user of the Borland AppServer (BAS) - so I'm guessing
here. BAS allows entities to be passivated even in the midst of
a transaction. But when activated, the ejbLoad() is called
and the state is synchronized with the current state in the database.
So when the client sends data, the entity bean has been 'refreshed'
with state in the database as would be expected. So the
the passivation/activation cycle is transparent to the client -
as it should be. So what is your quesiton?
-krish
===========================================================================
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".
