It means you could use session beans to get at the shared objects, but the
shared
objects themselves should probably Not be entity beans, but some kind of
CORBA
or RMI shared objects. Then you would have to think about whether these
shared objects
participate in EJB transactions or not.
<vendor>
In GemStone/J you could use Entity Beans for the shared objects and our
Peristence
Cache Architecture to share them. These would be transaction in the usual
sense,
but would benefit from our shared memory architecture.
</vendor>
-Chris.
> -----Original Message-----
> From: Booth, Peter [SMTP:[EMAIL PROTECTED]]
> Sent: Tuesday, April 27, 1999 10:42 AM
> To: [EMAIL PROTECTED]
> Subject: Re: Shared EJBs
>
> 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".
===========================================================================
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".
