What does this mean for applications that are mostly read-only?
For example, a graphing application where a server side in-memory cache
of DB data could be shared by many client processes? Assume that 99%
of accesses are reads, but there are occasional updates. Do EJBs add
any value to this scenario?
If, for simplicity, only one client is doing the updates, but many
clienets doing reads, does this change anything?
Peter Booth
[EMAIL PROTECTED]
> -----Original Message-----
> From: Chris Raber [SMTP:[EMAIL PROTECTED]]
> Sent: Tuesday, April 27, 1999 9:49 AM
> To: [EMAIL PROTECTED]
> Subject: Re: Shared EJBs
>
> Robert,
>
> I see a fundemental problem with what you want to achieve.
> If the data is shared, this implies some kind of isolation and concurrency
> controls
> when multiple clients want to update this information simultaneously. How
> can
> you accomplish this without transactions? Do you simply want to
> synchronize
> updates within the object itself, and provide isolation using Java
> features?
>
> One thought is to have a stateful CORBA or RMI based object which is
> shared.
> Clients
> would talk to session beans, which in turn talk to the stateful object.
> Updates to the
> stateful object would be synchronized using Java synchronization
> techniques.
> Clients
> of the session beans would be oblivious to the existence of the stateful
> object.
>
> One issue I see with this in general is how does this stateful object
> participate in
> EJB transactions? If the EJB transaction that was in effect when the
> stateful object
> was invoked is rolled back, how will rollback its state without
> transactional underpinnings?
> I suppose you could limit this exposure by making the session beans that
> wrap the
> stateful object be "Bean Managed Transaction". This would work, but then
> he
> beans
> would not be able to participate in transactions in other beans.
>
> It is important to understand that EJB is transaction centric. Trying to
> mix
> in non-transactional
> semantics is problematic. Stateful session beans can do this because their
> state is per
> client and not share, thus mitigating transaction isolation issues.
>
> -Chris.
>
> > -----Original Message-----
> > From: Robert Krueger [SMTP:[EMAIL PROTECTED]]
> > Sent: Tuesday, April 27, 1999 6:13 AM
> > To: [EMAIL PROTECTED]
> > Subject: Re: Shared EJBs
> >
> > Donald Edgar wrote:
> > >
> > > > We need to write objects that contain transient (non-presistent)
> data
> > that
> > > > needs to be shared among multiple clients. My understanding of
> > stateful
> > > > session EJBs is that they are meant to be instantiated and used by a
> > > single
> > > > client. What kind of EJBs should we use to implement a shared object
> > --
> > > for
> > > > instance an EJB that implements shared cache of some kind?
> > > >
> > >
> > > One technique we've used succesfully to share 'session beans' between
> > > multiple clients is to construct entity beans, with no persistent
> state,
> > > using well known primary keys. Singleton's can easily be constructed
> in
> > this
> > > manner by declaring a pk with no attributes.
> > >
> > > regards,
> > >
> > > Donald.
> > >
> >
> > But where does the transient shared data go, when the container decides
> > to remove your entity bean instance from memory? Maybe I'm missing
> > something but wasn't the problem sharing transient data? Maybe I
> > misunderstood the spec but I thought that there was no way to influence
> > whether a bean instance is kept in memory or not? If that is correct the
> > so-constructed Singleton would lose its state when being removed from
> > memory.
> >
> > Please correct me if I'm wrong.
> >
> > Regards,
> >
> > Robert
> >
> >
> > --
> > (-) Robert Kr�ger
> > (-) SIGNAL 7 Gesellschaft f�r Informationstechnologie mbH
> > (-) Br�der-Knau�-Str. 79 - 64285 Darmstadt,
> > (-) Tel: 06151 665401, Fax: 06151 665373
> > (-) [EMAIL PROTECTED], www.signal7.de
> >
> >
> ==========================================================================
> > =
> > 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".
