If the object is really readonly, it does not matter whether it is in a
transaction
or not. It also does not need to be shared.
If it is not readonly, then it does need to be shared because various
logical threads of control may be using it to communicate with each
other. This sort of communication has to be done under transaction
control - the two or more transactions must serialize on the shared
object.
In EJB, it is the container's responsibility to insure that only one
Java thread enters an EJB, and there is no requirement that
the container be responsible for things that are not EJBs.
But, controlling the threads is not enough because in a server
cluster, there may be multiple replicas of this shared object
on different processors of the cluster, and these replicas can
differ from each other. The resulting behavior is not what you
want in a shared object. A replica can only be updated if
all other replicas are locked against read. You can make this happen
in an Entity EJB by programming a datastore read on a connection
that is defined with serializable isolation each time someone tries
to read the value. The update operation performs a datastore
update. The datastore then handles synchronization across the
multiple processors in the cluster. There are other ways to
solve this problem. You could not allow replicas, in which case
everyone makes a remote method invocation to the shared
object (which is still an EJB). In heavily loaded situations,
the database is probably more efficient. Calling the database
is roughly equivalent to making a remote method invocation.
Jim
Jim Rhyne, STSM, Component Broker Tool Architect
[EMAIL PROTECTED], 416 448 4383
IBM Canada Ltd. 2G/846/1150/TOR
1150 Eglinton Ave. E., Toronto, Ont. M3C 1H7 CANADA
Chris Raber <[EMAIL PROTECTED]> on 04/27/99 02:22:50 PM
Please respond to A mailing list for Enterprise JavaBeans development
<[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
cc: (bcc: Jim Rhyne/Somers/IBM)
Subject: Re: Shared EJBs
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".
