"Lahooti, Hamid" wrote:
> A cache needs to be kept in sync with its data source.
> For that you need update notifications generated by
> data source.
Horsefeathers. Write-through caches solve this problem nicely without
requiring that the underlying data source perform any notifications
whatsoever. See WebLogic's white papers for a description of how they
(claim to) do this.
(Now, of course, the cache itself must perform notifications; I don't
dispute that.)
> To be a subscriber to events, you need
> singletons which are not supported in ejb spec.
This doesn't make any sense. Are you saying that something that plays
the "subscriber" role in a publish/subscribe system must be a
singleton? That is clearly false.
Caching is all fundamentally a question of how stale you are prepared to
allow your data to be. If you cannot allow it to be stale at all, then
you should not and cannot cache. If you are prepared for it to be only
mildly stale, then caching is a good option.
> So, to maintain entity data in sync with the database,
> there is only one way: refresh entity attributes from
> the database every time a new transaction starts.
No; reload cache once a write operation completes. If read operations
are all that have fired, then you don't need to reload the cache.
But suppose I accept your statement. In that case, how are session
beans (stateless or stateful) any different?
Cheers,
Laird
===========================================================================
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".
