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".
