• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Part II - session state for Java client

 
Greenhorn
Posts: 18
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
If a java client talks to ejb, and the container needs to create a unique session for this client (e.g. online shooping), is the ejb referrence stored in an object on java client, or similar to web client, there should be some object on the application server to store referrence?

I only know that web client use httpSession object to keep referrence to ejb object. HOw about java client? confusing.

Any help, will be very much appreciated.

Thanks,
 
Ranch Hand
Posts: 53
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi,

When using enterprise beans, it's best to maintain session state with stateful session beans in the EJB tier. For Web-only applications, maintain the state in the Web tier as session attributes (using HttpSession).
Reasons to prefer stateful session beans over other approaches to maintaining session state include:

Thread safety--Enterprise beans are thread-safe. By contrast, sophisticated thread-safe servlets are difficult to write.
Lifecycle management--The EJB container manages the lifecycle of enterprise beans components, automatically creating new instances, and activating and passivating instances as necessary to optimize performance.
Client type neutrality--Enterprise beans can be accessed, either directly or through some sort of adapter, from multiple client types. This contrasts with HTTP session attributes, which are available only to HTTP clients.
 
Ranch Hand
Posts: 114
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

the container needs to create a unique session for this client (e.g. online shooping),


Given that a shopping cart is a business operation, it seems to make sense to keep the session with an EJB. If you actually want to record the customer's choices between session, you'll have to do more than that and store it to a database, so entity beans or other data access methods may be required.

is the ejb referrence stored in an object on java client, or similar to web client, there should be some object on the application server to store referrence?



The Java client of a stateful session bean has a reference to it's very own bean instance - (one reason for controversy over scalability with stateful session bean).

I only know that web client use httpSession object to keep referrence to ejb object. HOw about java client? confusing.


The HttpSession uses cookies or url rewriting to maintain the link between web browser and the web server - no EJBs are involved here. You use a Java client to maintain a session with a stateful session bean. No need to get confused.
 
Ranch Hand
Posts: 18944
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi,
the Java Client contacts with the EJB reference by itself. I guess this is the best solution.
 
Greenhorn
Posts: 9
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
It may depend on the kind of information, you are willing to maintainj between session. If this session information is merely some defined datatype and for some specific set of requests, I will suggest to go for own implementation of session management in place of overkilling Statefull SessionBean.

regards
Rajeev
 
Don't get me started about those stupid light bulbs.
reply
    Bookmark Topic Watch Topic
  • New Topic