Yes, it does make sense... if you look at it from a non-object oriented
approach, a SSB could be like a library call... which is one of the goals
pursuited by the spec(my interpretation); see what I mean
public class Algo
{
private int a;
public void foo()
{
int b;
a=5;
b=5;
//other things
....
....
....
//here b=5
//a is undefined
}
}
I mean, variables defined within a method are heap managed, and thus present
no problem... if not, you DIRECTLY MUST AVOID SSBs
But if not, just define vars within each method, and benefit from optimized
use of memory.
And yes, it may be inconsistent with the tiny letter of the spec, but it
respects its spirit; after all, SSB exist merely to provide more reusable,
light components... if you need class scope state maintained, use Stateful
SB.
I respect the spec... but I'm asking for a discussion on this subject..
because I think the spec should be different... that's one of the things
this list is about, isn't it?
-----Original Message-----
From: Goud, Venkata [mailto:[EMAIL PROTECTED]]
Sent: Thursday, June 22, 2000 9:35 AM
To: [EMAIL PROTECTED]
Subject: Re: Correct me if i'm wrong
This can only occur if the bean goes to the pooled state in between
executing the method.
It does not make any sense to send the bean to the pooled state when a
method is being executed on the bean itself.
-----Original Message-----
From: Juan Pablo Lorandi [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, June 21, 2000 4:02 PM
To: [EMAIL PROTECTED]
Subject: Re: Correct me if i'm wrong
A given container may want to expose a SSB by instanciating it once; it
would present *mostly* no problem,
except if you use class members. Indeed, in a SSB there is no need for them.
So you may suppose that they won't be used, and use the same instance over
and over again
This is what some servlet engines do... it's not far fetched... I wouldn't
be surprised if any server behaves this way, it is a kind of optimization;
we can call it inconsistent, but I prefer this, to a server like OAS, that
creates a new object for every client(and destroys them for every client).
If the server vendor warns you, then it may appear incosistent, but it's
fair.
-----Original Message-----
From: Goud, Venkata [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, June 21, 2000 4:41 PM
To: [EMAIL PROTECTED]
Subject: Re: Correct me if i'm wrong
If it is true then it is inconsistent. Are you saying that for a stateless
session bean you should not have any class members.
class foo {
int i;
void foobar() {
i = 5;
somestatements; // some java statements which does not
effect i
nextstatements; // r u saying that i may not be 5 here?
}
}
-----Original Message-----
From: Juan Pablo Lorandi [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, June 21, 2000 3:16 PM
To: [EMAIL PROTECTED]
Subject: Re: Correct me if i'm wrong
Not necesarilliy true for stateless session beans. If the email value is a
class member, defined OUTSIDE the method that's executing, then you can't
assure this; tough such behavior could be considered a inconsistence in the
container
-----Original Message-----
From: Goud, Venkata [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, June 21, 2000 2:51 PM
To: [EMAIL PROTECTED]
Subject: Re: Correct me if i'm wrong
Client creates VisitorInfo bean and then calls a method on it. The email
value is undefined when you *just* enter into the method. If you have set
the email value by calling some other method on the same bean, then also
email value is undefined inside your method.
If you set the email value inside the method, then until the method finishes
executing, email value should remain unchanged.
-----Original Message-----
From: Greg Robertson [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, June 21, 2000 1:32 PM
To: [EMAIL PROTECTED]
Subject: Re: Correct me if i'm wrong
I'll take a look at the spec.
My question goes a little further though. The object in question is called
VisitorInfo. It stores the values necessary to decide who should get the
email. The email is going to the wrong person based upon the information
they are receiving (eg it appears 2 separate visitorinfos are being used at
the same time but during the same call). How would something like this
occur?
-----Original Message-----
From: Goud, Venkata [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, June 21, 2000 1:10 PM
To: [EMAIL PROTECTED]
Subject: Re: Correct me if i'm wrong
Make the bean stateful.
Please read about the Session bean's lifecycle in the specs
regs
Venkat
-----Original Message-----
From: Greg Robertson [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, June 21, 2000 12:46 PM
To: [EMAIL PROTECTED]
Subject: Re: Correct me if i'm wrong
The bean is stateless
-----Original Message-----
From: Goud, Venkata [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, June 21, 2000 11:48 AM
To: [EMAIL PROTECTED]
Subject: Re: Correct me if i'm wrong
Is it stateless or stateful?
-----Original Message-----
From: Greg Robertson [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, June 21, 2000 11:43 AM
To: [EMAIL PROTECTED]
Subject: Correct me if i'm wrong
I'm currently using Sun's RI for my EJB container. I just want to verify
that I am not making an incorrect assumption. The situation that is
occuring is a client attaches to my session bean which has some private
variables. This data is then used to determine which email address to send
info to. It appears that while the info is okay it is sometimes sending to
the wrong email address. This should not be due to multiple clients
attaching at the same time with different info should it? My understanding
is that a session bean is created for each client.
Thanks
===========================================================================
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".
===========================================================================
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".
===========================================================================
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".
