the assumption of this thread was that the ejb server *does* own the
database. i agree with you that in practice, this is most likely a rare
case. note that a program external to the database (legacy system, batch
job, etc) isn't required to mess the cache up. a simple stored procedure or
trigger in the database will do it.
> -----Original Message-----
> From: Eric R. Williams [SMTP:[EMAIL PROTECTED]]
> Sent: Monday, May 17, 1999 10:29 AM
> To: [EMAIL PROTECTED]
> Subject: Re: caching of beans was RE: EJBs and the internet
>
> Ian McCallion wrote:
> >
> > [...]
> > Yes, there needs to be coupling. It works roughly as follows:
> >
> > When a transaction running in a JVM completes, its transactional locks
> are
> > converted into cache locks (owned by the cache). If another transaction
> in
> > the same JVM needs the same data the cache lock is converted back to a
> > transactional lock and given to the transaction. If a transaction
> running
> > elsewhere needs the data it obtains the transactional lock. and when the
> > transaction completes (and assuming the data was updated) a notification
> is
> > sent to to any caches having a cache lock on the data and they flush the
> > now-invalid data.
>
> Good scheme... assuming that you are updating the data 100% through
> the entity beans. But when was the last time you were able to force
> all database users to go through a middleware layer? For one reason
> or another, you'll find updates happening to the database that don't
> go through EJB (legacy systems, batch jobs, and all the other places
> where EJB isn't appropriate). And therein lies the rub. The database
> isn't going to tell the EJB server to throw out its cached data, even
> though it has changed.
>
> -eric
>
> ==========================================================================
> =
> 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".
===========================================================================
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".
