Creating new session beans

When creating new session beans, create them in the WebSphereCommerceServerExtensionsData project.

About this task

Use the wizard provided within Rational Application Developer to create the necessary classes for the new session bean. For more information, see Creating session beans.

WebSphere Commerce uses access beans in its programming model, and access beans do not support local interfaces. To use local interfaces, instead of using access beans, you must perform home lookup directly and cache it yourself for performance purposes. Your new session bean should extend the class. The superclass provides methods that allow you to obtain a JDBC connection object from the data source object used by the WebSphere Commerce Server, so that the session bean participates in the same transaction as the other entity beans. The following is an example of code to demonstrate the functions provided by the superclass:

public class mySessionBean extends 
   implements SessionBean 

   public Object myMethod()
        throws javax.naming.NamingException, SQLException

      //  -- your logic, such as initialization --    // 

         try {
             // get a connection from the WebSphere Commerce data source
             PreparedStatement stmt = getPreparedStatement(
                "your sql string");
             // -- your logic such as set parameter into the prepared  //
             // statement --    																	  // 
             ResultSet rs = executeQuery(stmt, false);

					  while( {

             // -- your logic to process the result set -- //

          finally {
             // return the connection to the WebSphere Commerce
data source

       // -- your logic to return the result ---           //



In the preceding code example, the executeQuery method takes two input parameters. The first is a prepared statement and the second is a Boolean flag related to a cache flush operation. Set this flag to true if you need the container to flush all entity objects for the current transaction from the cache before executing the query. This would be required if you have performed updates on some entity objects and you need the query to search through these updated objects. If the flag were set to false those entity object updates would not be written to the database until the end of the transaction.

You should limit the use of this flush operation and generally set the flag to false, except in those cases where it is really required. The flush operation is a resource-intensive operation.