Jim,
You could flush objects out to the RDBMS, but your word 'eventually' must be
read as 'asynchronously'. Your application must be able to tolerate some
degree of lag between objects in the cache and data in the RDBMS. If you
use the RDMBS for reporting only (all updates occur via the application
server) this is not a problem. If you allow updates directly to the RDBMS,
you would have to read data in from the RDBMS into the app server in real
time and this is where the performance problems occur.
I have architected systems with a background process that flushes updates
from GemStone to an RDBMS or mainframe. I'd be happy to discuss how
off-line.
Also, you have to keep in mind that there is a big difference between
caching some of the data rows as objects in a volatile cache and caching all
of the data rows as objects in a persistent cache. If you don't get a
'cache hit' on every object, you need to go do an SQL query and RDBMS join
while the client is waiting.
David Brown
Systems Engineer
GemStone Systems Inc.
-----Original Message-----
From: James Cook [SMTP:[EMAIL PROTECTED]]
Sent: Thursday, February 26, 1998 4:12 PM
To: [EMAIL PROTECTED]
Subject: Re: Inter-Object Business Rules & EJB Transactions
I guess I would meet you halfway and say that it would be great if a
certain
vendor of a successful EJB product would allow elements from it's
persistent
cache to eventually be flushed to an RDBMS, but be available in
their latest
state at all times in the cache.
In the meantime, is there a better design to accomplish my simple
goal, or
is the only workable solution to spread logic between the database
*and* the
middle-tier?
jim
P.S. Aren't most EJB container vendors working on mechanisms to keep
EJBs
more readily available in some kind of local caching mechanism
instead of
persisting changes immediately to the database?
> -----Original Message-----
> From: A mailing list for Enterprise JavaBeans development
> [mailto:[EMAIL PROTECTED]]On Behalf Of Chris Raber
> Sent: Friday, February 26, 1999 12:55 PM
> To: [EMAIL PROTECTED]
> Subject: Re: Inter-Object Business Rules & EJB Transactions
>
>
> I can't recommend that kind of recursive iteration over
> entity beans, unless of course they were persisted with
> native persistence rather than JDBC.
>
> With native persistence the overhead of iterating over the beans
is
> no worse than using JDBC against a bunch of rows...
>
> If you must store the beans in an RDBMS, then I think you
> have to use SQL directly on them to get this to perform. So
> much for your component model...
>
> -Chris.
>
> > -----Original Message-----
> > From: James Cook [SMTP:[EMAIL PROTECTED]]
> > Sent: Wednesday, February 25, 1998 4:31 PM
> > To: [EMAIL PROTECTED]
> > Subject: Inter-Object Business Rules & EJB Transactions
> >
> > Imagine an organizational chart for your company comprised of
> many People
> > EJBs. Some People have descendants that represent their
> subordinates, and
> > these people have subordinates, etc. I have multiple clients
> that can make
> > changes to these objects.
> >
> > Suppose I have a business rule whereby, if a People EJB gets a
> bonus, the
> > same
> > bonus is applied to all of his/her subordinates. (Wish this was
real
> > life!)
> >
> > Stage set, here are the questions:
> >
> > 1) Would this business rule be enforced within a session EJB or
> the People
> > (entity) EJB?
> >
> > I will assume a session for the next questions...
> >
> > I can imagine a recursive routine that applies the bonus to the
> People EJB
> > in
> > question, gets a list of children, and calls itself for each
child. This
> > will
> > effectively traverse the branches.
> >
> > 2) Do the EJB transactions provide me with protection to prevent
someone
> > else
> > from modifying the first People EJB while I'm off changing
children.
> >
> > 3) Likewise, must I acquire some kind of lock on my entire set
of People
> > objects prior to making my changes. What if someone deletes a
People EJB
> > after
> > I get a list of children?
> >
> > 4) If one of my child People EJBs cannot have a new bonus
> applied (due to
> > some
> > other business rule) will/can all of the other object changes be
rolled
> > back?
> >
> > 5) One of the major strengths of the EJB framework is the
concept of
> > transactions. Are there any online resources to learn more
> about how these
> > work?
> >
> > Thanks,
> > 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".
>
> ==================================================================
> =========
> 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".
===========================================================================
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".
