|
The
last project I worked on (not shopping cart) used http session and not SSB and
had a kind of db fetch rutines to load what was needed if the http session was
flushed by some reason. This would not work for a shopping cart, because you
would have to store it in a database anyway, and would't need to store it in
session at all.
I've
heard general warnings about using SSB's, but unfortunately I cannot verify it,
and it might be outdated information. So when I say I don't know, thats really
what I mean ;-)
Oystein
Thanks Oystein,
that's much clearer. The only thing I would ask
is, if as you say
"I'm still not sure if I would recommend SSB used like this since
I really don't know how it performs,
and of cource it depends on the spesification of the overall
system."
then I wonder are stateful
session beans ever used in web apps at all? Isn't this meant to be their
entire
purpose?
thanks very
much,
Brian
----- Original Message -----
Sent: Wednesday, January 08, 2003 9:29
AM
Subject: SV: [Xdoclet-user] xPetStore
v2.1 released
Hi
Sorry for the confusion. If you have a statefull
session bean (SSB) you just store the reference to the bean in http session,
not the bean itself (At least with remote beans). The reference has
approximately fixed size, and the shopping cart does not. If you don't store
the reference then you would't have to create the bean on every
request, and that would give you a blank SSB every time. The
http session is used to fake state in a protocol that are stateless.
So, as an answere to your last question, you need
to store the SSB reference somewhere, and that somewhere could be http
session. As far as I know the http client can't store a bean, and if it
could i shouldn't be allowed to do it. That would give the client user
ability to modify it, and possibly do harm to your
system.
Shortly. When not using ejb's, all client state is
stored in http session. When using SSB, reference to klient state is stored
in http session and the "real" state in the
SSB.
As
an alternative you could use a session id (or something like
that) as a lookup key to get the SSB each request, but then you
would need some other mechanism to hold the references. Or you could use the
session id to query a database through a stateless session bean.
I'm still not sure if I would recommend SSB used
like this since I really don't know how it performs, and of cource it
depends on the spesification of the overall system.
Oystein
Thanks Oystein,
just to clear things up, does this mean that
if you're using a web tier (eg jsps) to contact an ejb tier containing a
stateful session bean, then the stateful session bean doesn't have to be
put in the HttpSession object? I'm getting quite confused unfortunately
:-(
My understanding is:
1) when not using ejb, the HttpSession object
is used to store client state between requests (possibly by writing
cookies to the client under the hood?)
2) when using ejb, a stateful session bean is
used to store client state between requests (possibly by writing cookies
to the client under the hood?).
If this is the case, why do we put stateful
session beans in the HttpSession object? If we have a direct reference to
the stateful session bean in the web client isn't this
enough?
thanks very much,
Brian
----- Original Message -----
Sent: Tuesday, January 07, 2003
3:02 PM
Subject: SV: [Xdoclet-user]
xPetStore v2.1 released
I haven't seen the example code in question,
but there is a significant difference between a plain java
object and a session bean. The plain object has to be stored fully in
the http session. The session bean could be stored somwhere in a cluster
environment whitch could handle load balansing and probably persistence.
( If the shopping cart contains much information the memory requirement
could be crutial. I've heard a lot of warnings about storing this kind
of information in the session object, but then again I've also heard
general warnings about using statefull session beans at all because of
memory requirements :) I don't now if this is still the
case.
Oystein
Hmm, this gets to the root of my
question. All the educational material
seems to show a shopping cart as the
perfect use for a stateful session
bean. However, if it's just put in the
HttpSession object in the web tier anyway,
could someone please tell me what is the purpose/advantage of using a
stateful session
bean?
Someone at work suggested that it might
be used to handle sessions between a
java app client and server. Is this
valid?
thanks,
Brian
----- Original Message -----
Sent: Monday, January 06, 2003
10:37 PM
Subject: RE: [Xdoclet-user]
xPetStore v2.1 released
Honestly, in real-world app, I would have used plain
Java Object stored in
HttpSession instead of
SFSB.
This was used more for educational
purpose :-)
-----Original Message-----
From: Brian McSweeney [mailto:[EMAIL PROTECTED]]
Sent: 06 January 2003 09:11
To: Herve Tchepannou; xdoclet
Subject: Re: [Xdoclet-user] xPetStore v2.1 released
Hi all,
excellent project
Herve. I have a real basic question to do with ejbs
though. You use a stateful session bean for the
shopping
cart implementation. When the
struts actions use the shopping cart they
store it in the HttpSession object. The thing I don't
understand is, how
does a stateful session
bean offer you more than just a plain java object?
If it is just being stored in the HttpSession object anyway,
what extra does
it offer you? Hope this
isn't too off the xdoclet topic.
thanks very
much
Brian
----- Original Message -----
From: "Herve Tchepannou"
<[EMAIL PROTECTED]>
To:
"xdoclet" <[EMAIL PROTECTED]>; "jboss"
<[EMAIL PROTECTED]>
Sent: Sunday, January 05, 2003 7:17 AM
Subject: [Xdoclet-user] xPetStore v2.1 released
> I'm Proud to annouce a new release of xPetStore
v2.1
>
>
xPetStore is a WODRA (Write Once, Deploy and Run Anyware)
implementation
> of Sun
> PetStore application based on the following opensource
tools/frameworks:
> - xDoclet
> - Struts
> -
Sitemesh
>
>
xPetStore has been successfully deployed and tested on the
following
> application servers:
> - JBoss
> -
WebLogic
>
>
You can download the lattest version of xPetStore at
> http://sourceforge.net/projects/xpetstore
>
>
-----------
> This release has the
following changes:
> - Integration with
JUnitEE
> - Simplify the installation
process highly simplify
> - Spilt
build.xml to reduce the complexity of the build process
> - Mailing list created at sourceforge
net
> - Bug fixes
> --
>
> Herve Tchepannou
> mailto:[EMAIL PROTECTED]
>
>
>
>
-------------------------------------------------------
> This sf.net email is sponsored
by:ThinkGeek
> Welcome to geek
heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Xdoclet-user mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/xdoclet-user
>
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Xdoclet-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/xdoclet-user
|
