Enero de 2001 20:29
> To: Orion-Interest
> Subject: RE: Session EJB Accessibility
>
>
> I'm confused by your comments; does it need to manage state,
> or doesn't
> it? I'm assuming it does, otherwise you would just use a stateless
> session bean.
>
>
etty fair discussion of
isolation levels:
http://jsp.java.sun.com/javaone/javaone2000/event.jsp?eventId=678
Jeff
>-Original Message-
>From: Dan Winfield [mailto:[EMAIL PROTECTED]]
>Sent: Wednesday, January 31, 2001 12:36 AM
>To: Orion-Interest
>Subject: Re: Session EJB Accessib
y read and optimistic concurrency preclude eachother. In
any case, "dirty read" refers to reading, OC to writing.
- Original Message -
From: "Dan Winfield" <[EMAIL PROTECTED]>
To: "Orion-Interest" <[EMAIL PROTECTED]>
Sent: Wednesday, January 31, 2001 9:3
>
Sent: Wednesday, January 31, 2001 7:52 AM
Subject: Re: Session EJB Accessibility
> I believe Orion uses pessimistic concurrency control. However, I don't
> think optimistic concurrency control would allow dirty reads -- I
understand
> a dirty read to imply a transaction seeing
I believe Orion uses pessimistic concurrency control. However, I don't
think optimistic concurrency control would allow dirty reads -- I understand
a dirty read to imply a transaction seeing the uncommitted state of another
transaction.
Vidur
Jeff Schnitzer wrote:
> >From: Gary Shea [mailto:[E
>From: Mark Bernardinis [mailto:[EMAIL PROTECTED]]
>
>> It seems like what you want is either a SLSB which never
>times out and
>> is guaranteed to only have one instance in the pool, or a BMP entity
>> bean with a guarantee of serialized transactions.
>>
>
>This is exactly what I want to do. Th
>From: Gary Shea [mailto:[EMAIL PROTECTED]]
>
>I could use a little help here. My limited understanding of entity
>beans suggests that if I create an EB using a particular
>key value, as long as I refer only to that same key value there
>would only be one instance of the EB. Is that not true bec
red solution?
>>
>> I propose that the only server-independent way to do what you want is
>> to use an RMI server. The EJB specification really needs a
>> "SingletonBean", preferrably one which allows concurrent calls (and
>> thus reasonable performance).
&g
-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Gary Shea
Sent: Tuesday, January 30, 2001 8:46 PM
To: Orion-Interest
Subject: RE: Session EJB Accessibility
I could use a little help here. My limited understanding of entity
beans suggests that if I create an EB using a
The EJB specification really needs a
> "SingletonBean", preferrably one which allows concurrent calls (and
> thus reasonable performance).
>
> Comments?
>
> Jeff
>
>
>>-Original Message-
>>From: Mark Bernardinis [mailto:[EMAIL PROTECTED]]
&g
easonable performance).
>
> Comments?
>
> Jeff
>
>
> >-----Original Message-
> >From: Mark Bernardinis [mailto:[EMAIL PROTECTED]]
> >Sent: Tuesday, January 30, 2001 12:18 AM
> >To: Orion-Interest
> >Subject: Re: Session EJB Accessibility
> >
&g
ROTECTED]]
>Sent: Tuesday, January 30, 2001 12:18 AM
>To: Orion-Interest
>Subject: Re: Session EJB Accessibility
>
>
>I don't want to do any database activity. I just want this
>Java Object to be
>accessible as an EJB accessible by many different clients hosted by an
Interest
> Subject: RE: Session EJB Accessibility
>
>
> use stateless session bean, it can serve multiple clients
> concurrently.
>
> > -Original Message-
> > From: Mark Bernardinis [SMTP:[EMAIL PROTECTED]]
> > Sent: Tuesday, January
use stateless session bean, it can serve multiple clients concurrently.
> -Original Message-
> From: Mark Bernardinis [SMTP:[EMAIL PROTECTED]]
> Sent: Tuesday, January 30, 2001 3:18 AM
> To: Orion-Interest
> Subject: Re: Session EJB Accessibility
>
> I
a stateless session bean with its fields set
up as
public static MyFieldType myfield;
won't do? (altough obviously a multi VM solution totally craps this pattern)
-Original Message-
From: Mark Bernardinis [mailto:[EMAIL PROTECTED]]
Sent: Martes, 30 de Enero de 2001 5:18
To: Orion-In
Today, Mark Bernardinis ([EMAIL PROTECTED]) wrote:
> I don't want to do any database activity. I just want this Java Object to be
> accessible as an EJB accessible by many different clients hosted by an
> Application Server. The object doesn't have to be stateful either.
I suspect the problem wit
tic MyFieldType myfield;
won't do? (altough obviously a multi VM solution totally craps this pattern)
-Original Message-
From: Mark Bernardinis [mailto:[EMAIL PROTECTED]]
Sent: Martes, 30 de Enero de 2001 5:18
To: Orion-Interest
Subject: Re: Session EJB Accessibility
I don'
You can still use an entity bean to provide this functionality. Nothing in
the specification states that the persistent store has to be a database. So
design your bean to be a BMP entity bean, then handle the loading and saving
of your data in your ejbLoad and ejbStore methods. You can serialize
I don't want to do any database activity. I just want this Java Object to be
accessible as an EJB accessible by many different clients hosted by an
Application Server. The object doesn't have to be stateful either.
> It sounds like you're describing an entity bean more than a session
> bean. An
It sounds like you're describing an entity bean more than a session
bean. An entity bean can be called by many clients although access
is serialized. And certainly the role of an entity bean is to
encapsulate data in a apparently-storage-mechanism-independent manner,
from the client's perspectiv
20 matches
Mail list logo
