Session Bean Component Contract

[Charles O'Leary]

Hey ranchers

A session bean instance is an extension of the client that creates it:

• It typically reads and updates data in a database on behalf of the client.

Typically, a session object’s conversational state is not written to the database.

The file system APIs are not well-suited for business components to access data. Business components
should use a resource manager API, such as JDBC, to store data.

Again, typically, a session object’s conversational state is not written to the database. Especially since the following text continues to detail how data should be written to the database with and without the Java Persistence API, how is this not a contradiction and/or please tell me what I'm missing here?

(follows above quotes)

A session bean that does not make use of the Java Persistence API must explicitly manage cached database
data. A session bean instance must write any cached database updates prior to a transaction completion,
and it must refresh its copy of any potentially stale database data at the beginning of the next
transaction. A session bean must also refresh any java.sql Statement objects before they are used in
a new transaction context. Use of the Java Persistence API provides a session bean with automatic management
of database data, including the automatic flushing of cached database updates upon transaction
commit.

[Frits Walraven]

Hi Charles,

I don't fully understand your question but maybe the confusion is about the definition of "conversational state". Taken from the EE6 tutorial:

Stateful Session Beans
The state of an object consists of the values of its instance variables. In a stateful session bean, the instance variables represent the state of a unique client/bean session. Because the client interacts (“talks”) with its bean, this state is often called the conversational state.
As its name suggests, a session bean is similar to an interactive session. A session bean is not shared; it can have only one client, in the same way that an interactive session can have only one user. When the client terminates, its session bean appears to terminate and is no longer associated with the client.
The state is retained for the duration of the client/bean session. If the client removes the bean, the session ends and the state disappears. This transient nature of the state is not a problem, however, because when the conversation between the client and the bean ends, there is no need to retain the state.

In other words: the conversational state is not meant to be written to the database, it is only useful in the client-bean communication.

Does this clear up your doubts?

[Charles O'Leary]

Unfortunately, my path isn't clear yet. Thanks for taking my question Frits.

A session bean instance is an extension of the client that creates it:
• In the case of a stateful session bean, its fields contain a conversational state on behalf of the
session object’s client. This state describes the conversation represented by a specific client/
session object pair.
• It typically reads and updates data in a database on behalf of the client.
• In the case of a stateful session bean, its lifetime is controlled by the client.

It's clear and explicit that the first and third bullets are specific to stateful session beans.

What's your interpretation of the 2nd bullet? Is the second bullet specific to stateless session beans? In other words, what does the "It" mean specifically in the second bullet and/or is the second bullet representative of either stateful, stateless, OR both stateful and stateless session beans?

[Frits Walraven]

In other words, what does the "It" mean specifically in the second bullet and/or is the second bullet representative of either stateful, stateless, OR both stateful and stateless session beans?

Yes, in this case it can be for any type of Session bean because all of them have clients. The difference is that a stateless session bean does not hold any conversational state for a specific client. From a stateless-client-perspective it doesn't matter which bean will serve him.

[Charles O'Leary]

Typically, stateful session beans AND stateless session beans (by definition) read and update non-conversational data in the database on behalf of the client. Correct?

Thanks again Frits.