----- Original Message -----
From: "Rickard �berg" <[EMAIL PROTECTED]>
> Yes. The "more details" I referred to is basically the
> timestamping outlined above. (and now you're going to
> say that the "outline" is too vague too... ack.. ;-)
I won't say it's vague since it is similar to what we do now, we just don't
call it a cache. :-)
The risk of stale data is not so good for most of the apps I have written. I
agree that you could put read-only data in a cache since it isn't going to
change. I don't think developers have a lot of issues with that anyway. They
can just mark their beans to use option a, or they can just use SLSB.
The other thing that is not good with the approach is the amount of
asynchronous messaging. That's a lot of extra traffic on the network. I
would imagine that it would be a drain after a certain threshold of
transactions are met.
It would be interesting to see if the solution you presented would actually
be faster in practice. I'm not so sure it would. And the risk of stale data
shoots it down for many of us anyway.
I think EJB needs a helper framework (not part of spec) to help in
concurrency issues. Everyone still rolls their own, and I feel the majority
of developers do not even realize the concurrency problems in their
applications.
jim
===========================================================================
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".
