com.ibm.websphere.ejbpersistence

Interface EJBToRAAdapter



  • public interface EJBToRAAdapter
    Interface for adapting between the WebSphere CMP 2.0 support layer and a J2EE Connector interface (a.k.a. J2C) Resource Adapter (RA). This includes converting the input parameters of a CMP 2.0 entity CRUD method to the input parameters needed by the corresponding RA function(s), and likewise converting the output and error indications from the RA function(s) to the Java return value and exceptions required by PM and CMP 2.0. The purpose of implementing this interface is to allow an RA (existing or new)to be used as an alternative "back-end" which can persist the data for CMP 2.0 entity beans. The existance of an implementation of this interface is not alone suffficient to enable an RA to be used as such a back-end. Certain of the classes generated by the WebSphere CMP 2.0 Deploy Tool are specific to the back-end; a new back-end must provide a way for these classes to be generated (or othewise produced) in a way compatible with it's requirement.One such generated class, which extends BeanAdaptorBinding, has a method which returns an instance of your RA's implementation of this interface; that is how your EJBToRAAdapter implementation, and thus your RA, is plugged into the WebSphere CMP 2.0 support layer (you must still register your RA as you would any RA). See documentation on the Deploy Tool and the WebSphere CMP 2.0 support for details on this aspect of plugging a 3rd party Resource Adapter into WebSphere's CMP 2.0 support. In addition to its stated purpose above, an implmementation of this interface may also perform any pre-and post-execute processing it desires, provided this processing does not break the interface defined herein.
    • Method Summary

      Methods 
      Modifier and Type Method and Description
      boolean checkBackendId(javax.resource.cci.ConnectionFactory connectionFactory, java.lang.String backendId)
      Return if currentBackendId is valid for the datasource connection factory connected to .
      javax.resource.cci.Interaction createInteraction(javax.resource.cci.Connection conn)
      Deprecated. 
      (From WAS 6.0)
      javax.resource.cci.Interaction createInteraction(javax.resource.cci.Connection conn, AccessIntent intent, java.util.HashMap properties)
      Using the given Connection object, call its "createInteraction()" method; the Interaction returned from that call is also returned by this method.
      javax.resource.cci.Record executeCreate(javax.resource.cci.Interaction interaction, javax.resource.cci.InteractionSpec ispec, javax.resource.cci.IndexedRecord inputRecord)
      Using the given Interaction object, call its "execute(InteractionSpec ispec, Record inrec)" method with the given InteractionSpec and input Record; the Record returned from that call is also returned by this method.
      javax.resource.cci.Record executeCreate(javax.resource.cci.Interaction interaction, javax.resource.cci.InteractionSpec ispec, javax.resource.cci.IndexedRecord[] inputRecord)
      This is the batch create
      javax.resource.cci.Record executeFinder(javax.resource.cci.Interaction interaction, javax.resource.cci.InteractionSpec ispec, javax.resource.cci.IndexedRecord inputRecord)
      Using the given Interaction object, call its "execute(InteractionSpec ispec, Record inrec)" method with the given InteractionSpec and input Record; the Record returned from that call is also returned by this method (see next paragraph for specifics on the Record returned).
      javax.resource.cci.Record executeOther(javax.resource.cci.Interaction interaction, javax.resource.cci.InteractionSpec ispec, javax.resource.cci.IndexedRecord inputRecord)
      Using the given Interaction object, call its "execute(InteractionSpec ispec, Record inrec)" method with the given InteractionSpec and input Record; the Record returned from that call may also be returned by this method, or a new Record may be constructed by this method to further post-process the returned data.
      javax.resource.cci.Record executeOther(javax.resource.cci.Interaction interaction, javax.resource.cci.InteractionSpec ispec, javax.resource.cci.IndexedRecord[] inputRecord)
      this is the batch executeOther
      boolean[] executeReadReadChecking(javax.resource.cci.Interaction interaction, javax.resource.cci.InteractionSpec ispec, javax.resource.cci.IndexedRecord[] input)
      Execute read read checking
      javax.resource.cci.Record executeRemove(javax.resource.cci.Interaction interaction, javax.resource.cci.InteractionSpec ispec, javax.resource.cci.IndexedRecord[] inputRecord, javax.resource.cci.IndexedRecord[] predicates)
      This is the batch remove
      javax.resource.cci.Record executeRemove(javax.resource.cci.Interaction interaction, javax.resource.cci.InteractionSpec ispec, javax.resource.cci.IndexedRecord inputRecord, javax.resource.cci.IndexedRecord predicates)
      Using the given Interaction object, call its "execute(InteractionSpec ispec, Record inrec)" method with the given InteractionSpec and input Record; the Record returned from that call is also returned by this method.
      javax.resource.cci.Record executeUpdate(javax.resource.cci.Interaction interaction, javax.resource.cci.InteractionSpec ispec, javax.resource.cci.IndexedRecord[] inputrec, javax.resource.cci.IndexedRecord[] predicates, boolean[][] dirtyBits, java.lang.String cursorName)
      this is the batch update
      javax.resource.cci.Record executeUpdate(javax.resource.cci.Interaction interaction, javax.resource.cci.InteractionSpec ispec, javax.resource.cci.IndexedRecord inputrec, javax.resource.cci.IndexedRecord predicates, boolean[] dirtyBits, java.lang.String cursorName)
      Using the given Interaction object, call its "execute(InteractionSpec ispec, Record inrec)" method with the given InteractionSpec and input Record; the Record returned from that call is also returned by this method.
      javax.resource.cci.Connection getConnection(javax.resource.cci.ConnectionFactory connectionFactory, AccessIntent accessIntent)
      Using the given ConnectionFactory object, call its "getConnection(javax.resource.cci.ConnectionFactory factory, javax.resource.cci.ConnectionSpec connSpec)" method, creating the ConnectionSpec subclass (if any) designed to work for the given ConnectionFactory subclass.
      int getLockType(javax.resource.cci.ConnectionFactory connectionFactory, AccessIntent accessIntent)
      Return the Lock Type basing on the current backend information and AccessIntent This method returns a value indicating what sort of locking behavior is needed when executing the requested method.
      int getLockType(javax.resource.cci.ConnectionFactory connectionFactory, AccessIntent accessIntent, java.util.HashMap properties)
      534869 fix: introduce a new parameter: Hashmap properties to adapter class, WSEJBToRAAdapter which implements PM interface EJBToRAAdapter.
      java.lang.Object getNativeConnection(javax.resource.cci.Connection conn)
      Return the native connection corresponding to the given cci.Connection, or null if there is no "native" connection.
      javax.resource.cci.RecordFactory getRecordFactory(javax.resource.cci.ConnectionFactory connectionFactory)
      Return the RecordFactory for the given ConnectionFactory.
      boolean isBatchSupported(javax.resource.cci.ConnectionFactory connectionFactory, AccessIntent accessIntent)
      Return if batch is supported basing on the current backend information and AccessIntent
    • Method Detail

      • createInteraction

        javax.resource.cci.Interaction createInteraction(javax.resource.cci.Connection conn)
                                                         throws javax.resource.ResourceException
        Deprecated. (From WAS 6.0)
        Using the given Connection object, call its "createInteraction()" method; the Interaction returned from that call is also returned by this method. See the J2EE Connector (J2C) spec for details on these types. Prior to calling Connection.createInteraction(), the implementer may perform any necessary pre-processing to adapt the incoming parameters to the needs of the Resource Adapter being called. After return from the call to the RA, the implementer must perform any necessary post-processing to adapt the return value to this interface. Creation date: (11/5/2001 10:06:22 AM)
        Parameters:
        conn - javax.resource.cci.Connection see J2EE Connector spec, CCI
        Returns:
        javax.resource.cci.Interaction see J2EE Connector spec, CCI
        Throws:
        javax.resource.ResourceException
      • createInteraction

        javax.resource.cci.Interaction createInteraction(javax.resource.cci.Connection conn,
                                                       AccessIntent intent,
                                                       java.util.HashMap properties)
                                                         throws javax.resource.ResourceException
        Using the given Connection object, call its "createInteraction()" method; the Interaction returned from that call is also returned by this method. See the J2EE Connector (J2C) spec for details on these types. Prior to calling Connection.createInteraction(), the implementer may perform any necessary pre-processing to adapt the incoming parameters to the needs of the Resource Adapter being called. After return from the call to the RA, the implementer must perform any necessary post-processing to adapt the return value to this interface. Creation date: (11/5/2001 10:06:22 AM)
        Parameters:
        conn - javax.resource.cci.Connection see J2EE Connector spec, CCI
        intent - the AccessIntent in effect for this operation. The values in intent shall be used as necessary when executing the returned interaction. The values include choice of pessimistic versus optimistic access, intent to read versus update the data, and others. See the javadoc for AccessIntent for additional details.
        property - HashMap, the additional information for point releases. Will pass null for now.
        Returns:
        javax.resource.cci.Interaction see J2EE Connector spec, CCI
        Throws:
        javax.resource.ResourceException
      • executeCreate

        javax.resource.cci.Record executeCreate(javax.resource.cci.Interaction interaction,
                                              javax.resource.cci.InteractionSpec ispec,
                                              javax.resource.cci.IndexedRecord inputRecord)
                                                throws javax.ejb.CreateException,
                                                       javax.resource.ResourceException
        Using the given Interaction object, call its "execute(InteractionSpec ispec, Record inrec)" method with the given InteractionSpec and input Record; the Record returned from that call is also returned by this method. However, no Record should be returned from this call, null is expected. By definition, the function being executed is on behalf of ejbCreate. The shape of the input IndexedRecord is specific to the particular RA function being executed. See the J2EE Connector (J2C) spec for details on these types. Prior to calling Interaction.execute(...), the implementer may perform any necessary pre-processing to adapt the incoming parameters to the needs of the Resource Adapter function being executed. After return from the call to Interaction.execute(...), the implementer must perform any necessary post-processing to adapt the return value to this interface (which was defined specifically with ejbCreate in mind). MOST IMPORTANTLY, indication of certain errors must be converted from how the called function indicates them to the requirements of this interface. Specifically:
        1. duplicate keys must be detected and must result in a javax.ejb.DuplicateKeyException. Note that this method may also be used for creating private objects such as entries in a "join" table which implements a many-to-many relationship; although the EJB specification says such creates may not return DuplicateKeyException (as unlikely as it would be for such an error to occur), the PM runtime takes care of converting any DuplicateKeyException to an EJB-acceptable exception when the call is not for an actual ejbCreate. Creation date: (11/5/2001 10:06:22 AM)
        Parameters:
        interaction - javax.resource.cci.Interaction the interaction this method should call "execute(...)" on
        ispec - javax.resource.cci.InteractionSpec see J2EE Connector spec, CCI
        inputRecord - javax.resource.cci.IndexedRecord see J2EE Connector spec, CCI. This parameter may be null, which indicates there are no input parameters for this function.
        Returns:
        javax.resource.cci.Record see J2EE Connector spec, CCI
        Throws:
        javax.ejb.CreateException
        javax.resource.ResourceException
      • executeCreate

        javax.resource.cci.Record executeCreate(javax.resource.cci.Interaction interaction,
                                              javax.resource.cci.InteractionSpec ispec,
                                              javax.resource.cci.IndexedRecord[] inputRecord)
                                                throws javax.ejb.CreateException,
                                                       javax.resource.ResourceException
        This is the batch create
        Throws:
        javax.ejb.CreateException
        javax.resource.ResourceException
      • executeFinder

        javax.resource.cci.Record executeFinder(javax.resource.cci.Interaction interaction,
                                              javax.resource.cci.InteractionSpec ispec,
                                              javax.resource.cci.IndexedRecord inputRecord)
                                                throws javax.ejb.FinderException,
                                                       javax.resource.ResourceException
        Using the given Interaction object, call its "execute(InteractionSpec ispec, Record inrec)" method with the given InteractionSpec and input Record; the Record returned from that call is also returned by this method (see next paragraph for specifics on the Record returned). By definition, the function being executed is on behalf of an EJB finder (including private EJB finders and private CMP "field" finders). The shape of the input IndexedRecord is specific to the particular RA function being executed. See the J2EE Connector (J2C) spec for details on these types. Prior to calling Interaction.execute(...), the implementer may perform any necessary pre-processing to adapt the incoming parameters to the needs of the Resource Adapter function being executed. After return from the call to Interaction.execute(...), the implementer must perform any necessary post-processing to adapt the return value to this interface (which was defined specifically with EJB finders in mind). The Record returned from this method must match a specific format. First, the return type must be either javax.resource.cci.ResultSet or javax.resource.cci.IndexedRecord. At this time, javax.resource.cci.MappedRecord is not allowed; this method can convert a MappedRecord to an IndexedRecord, of course. If you return an IndexedRecord, this "result" IndexedRecord must contain zero or more other "row" IndexedRecords. Each "row" IndexedRecord serves the same purpose as a row in a ResultSet. A "row" IndexedRecord contains the Java objects (Strings, Integers, etc.) which form the data for a particular bean instance. The order and types of the Java objects in a "row" record (a.k.a. the "shape" of the row record) must be the same for each "row" record in the "result" record. Furthermore, the shape must match the shape expected by the Extractor class generated (or otherwise produced) by your RA-specific bean deployment mechanism (see class-level doc for this class). MOST IMPORTANTLY, indication of certain errors must be converted from how the called function indicates them to the requirements of this interface. Specifically:
        1. a call to a single-object finder (e.g., findByPrimaryKey(...) ) must detect that the object with the given key was not found and, if not found, must return an empty ResultSet or result Record. Runtime code in PM will detect this and throw javax.ejb.ObjectNotFoundException as defined in the EJB 2.0 spec. Creation date: (11/5/2001 10:06:22 AM)
        Parameters:
        interaction - javax.resource.cci.Interaction the interaction this method should call "execute(...)" on
        ispec - javax.resource.cci.InteractionSpec see J2EE Connector spec, CCI
        inputRecord - javax.resource.cci.IndexedRecord see J2EE Connector spec, CCI.This parameter may be null, which indicates there are no input parameters for this function.
        Returns:
        javax.resource.cci.Record
        Throws:
        javax.resource.ResourceException - The exception description.
        javax.ejb.FinderException
      • executeRemove

        javax.resource.cci.Record executeRemove(javax.resource.cci.Interaction interaction,
                                              javax.resource.cci.InteractionSpec ispec,
                                              javax.resource.cci.IndexedRecord inputRecord,
                                              javax.resource.cci.IndexedRecord predicates)
                                                throws javax.ejb.RemoveException,
                                                       javax.resource.ResourceException
        Using the given Interaction object, call its "execute(InteractionSpec ispec, Record inrec)" method with the given InteractionSpec and input Record; the Record returned from that call is also returned by this method. However, no Record should be returned from this call, null is expected. By definition, the function being executed is on behalf of ejbRemove. The shape of the input IndexedRecord is specific to the particular RA function being executed. See the J2EE Connector (J2C) spec for details on these types. Prior to calling Interaction.execute(...), the implementer may perform any necessary pre-processing to adapt the incoming parameters to the needs of the Resource Adapter function being executed. After return from the call to Interaction.execute(...), the implementer must perform any necessary post-processing to adapt the return value to this interface (which was defined specifically with ejbRemove in mind). MOST IMPORTANTLY, indication of certain errors must be converted from how the called function indicates them to the requirements of this interface. Specifically:
        1. absence of the object to be removed must be detected and must result in throwing javax.ejb.NoSuchEntityException Creation date: (11/5/2001 10:06:22 AM)
        Parameters:
        interaction - javax.resource.cci.Interaction the interaction this method should call "execute(...)" on
        ispec - javax.resource.cci.InteractionSpec see J2EE Connector spec, CCI
        inputRecord - javax.resource.cci.Record input Record, see J2EE Connector spec, CCI.This parameter may be null, which indicates there are no input parameters for this function.
        javax.resource.cci.IndexedRecord - predicates PM-specific data class holding old values for optimistic concurrency control. The size and shape (element types) of this record are the same as that defined for this EJB type. We should not update this bean if any attribute has been changed from its old value by some other user of this data store. This parameter may be null which indicates no predicate checking should be done.
        Returns:
        javax.resource.cci.Record see J2EE Connector spec, CCI
        Throws:
        javax.resource.ResourceException - The exception description.
        javax.ejb.RemoveException
      • executeRemove

        javax.resource.cci.Record executeRemove(javax.resource.cci.Interaction interaction,
                                              javax.resource.cci.InteractionSpec ispec,
                                              javax.resource.cci.IndexedRecord[] inputRecord,
                                              javax.resource.cci.IndexedRecord[] predicates)
                                                throws javax.ejb.RemoveException,
                                                       javax.resource.ResourceException
        This is the batch remove
        Throws:
        javax.ejb.RemoveException
        javax.resource.ResourceException
      • executeUpdate

        javax.resource.cci.Record executeUpdate(javax.resource.cci.Interaction interaction,
                                              javax.resource.cci.InteractionSpec ispec,
                                              javax.resource.cci.IndexedRecord inputrec,
                                              javax.resource.cci.IndexedRecord predicates,
                                              boolean[] dirtyBits,
                                              java.lang.String cursorName)
                                                throws javax.ejb.EJBException,
                                                       javax.resource.ResourceException
        Using the given Interaction object, call its "execute(InteractionSpec ispec, Record inrec)" method with the given InteractionSpec and input Record; the Record returned from that call is also returned by this method. However, no Record should be returned from this call, null is expected. By definition, the function being executed is on behalf of ejbUpdate. The shape of the input IndexedRecord is specific to the particular RA function being executed. See the J2EE Connector (J2C) spec for details on these types. Prior to calling Interaction.execute(...), the implementer may perform any necessary pre-processing to adapt the incoming parameters to the needs of the Resource Adapter function being executed. After return from the call to Interaction.execute(...), the implementer must perform any necessary post-processing to adapt the return value to this interface (which was defined specifically with ejbUpdate in mind). This method API passes certain interaction-related info (e.g., optimistic concurrency info, such as "predicates" and "dirtyElements") in a PM-standard way. An EJBToRAAdapter may choose to make use of it or ignore it. MOST IMPORTANTLY, indication of certain errors must be converted from how the called function indicates them to the requirements of this interface. Specifically:
        1. absence of the object to be updated must be detected and must result in throwing javax.ejb.NoSuchEntityException Creation date: (11/5/2001 10:06:22 AM)
        Parameters:
        interaction - javax.resource.cci.Interaction the interaction this method should call "execute(...)" on
        ispec - javax.resource.cci.InteractionSpec see J2EE Connector spec, CCI
        inputrec - javax.resource.cci.IndexedRecord input Record, see J2EE Connector spec, CCI.This parameter may be null, which indicates there are no input parameters for this function. This is not normal but you should code to handle it (for example., by ignoring the update request).
        javax.resource.cci.IndexedRecord - predicates PM-specific data class holding old values for optimistic concurrency control. The size and shape (element types) of this record are the same as that defined for this EJB type. Elements not changed are ignored (see dirtyBits, below). We should not update this bean if any updated attribute has been changed from its old value by some other user of this data store. This parameter may be null, which indicates no predicate checking should be done.
        boolean[] - dirtyBits PM-specific array of boolean, each corresponding to an element in "predicates". Any element in "predicates" which has changed since the last read from the backend (e.g., a "finder") must have it's corresponding boolean element in "dirtyBits" set to true. This parameter may be null, which indicates no predicate checking should be done.
        cursorName - java.lang.String an optional cursor name, obtained by PM runtime via a call to java.sql.ResultSet.getCursorName(), using the ResultSet which contains the bean/row being updated. This parameter is used to perform "positional update", a more efficient data updating mechanism supported by certain Resource Managers (mostly, relational databases). If a Resource Adapter does not support positioned update then this parameter can be ignored.
        Returns:
        javax.resource.cci.Record see J2EE Connector spec, CCI
        Throws:
        javax.resource.ResourceException - The exception description.
        javax.ejb.EJBException
      • executeUpdate

        javax.resource.cci.Record executeUpdate(javax.resource.cci.Interaction interaction,
                                              javax.resource.cci.InteractionSpec ispec,
                                              javax.resource.cci.IndexedRecord[] inputrec,
                                              javax.resource.cci.IndexedRecord[] predicates,
                                              boolean[][] dirtyBits,
                                              java.lang.String cursorName)
                                                throws javax.ejb.EJBException,
                                                       javax.resource.ResourceException
        this is the batch update
        Throws:
        javax.ejb.EJBException
        javax.resource.ResourceException
      • executeOther

        javax.resource.cci.Record executeOther(javax.resource.cci.Interaction interaction,
                                             javax.resource.cci.InteractionSpec ispec,
                                             javax.resource.cci.IndexedRecord inputRecord)
                                               throws javax.resource.ResourceException
        Using the given Interaction object, call its "execute(InteractionSpec ispec, Record inrec)" method with the given InteractionSpec and input Record; the Record returned from that call may also be returned by this method, or a new Record may be constructed by this method to further post-process the returned data. A Record may or may not be returned from this call, depending on the particular function being executed (the function is named in the InteractionSpec). By definition, the function being executed is other than the currently defined ones (create, finder, etc). There are currently two uses of executeOther(...). The first is for updating the Many-Many Auxilary tables (typically only necessary for relational Resource Adapters). The value returned from this execution must be null. The second is for executing data logic method functions (sometimes called "pushdown methods"). In a CMP bean, a data logic method is any method which is not ejbCreate, ejbUpdate, ejbDelete or a finder (public or private). A data logic method can be implemented completely in Java code residing in the CMP bean itself, in which case there is no data logic method function to be executed via "executeOther(...)". A data logic method can also be implemented as a database stored procedure or other EIS function (as defined in the J2EE Connector specification). Such a data logic method appears as a regular method on a CMP bean but, when that method is called, generated and hand-written code calls the underlying datastore function (stored proc, EIS, whatever) via "executeOther(...)". The function to be called is named in the given InteractionSpec "ispec" and the parameters it needs are passed in the given IndexedRecord "inputRecord". The shape of the input IndexedRecord is specific to the particular RA function being executed. See the J2EE Connector (J2C) spec for details on these types. Prior to calling Interaction.execute(...), the implementer may perform any necessary pre-processing to adapt the incoming parameters to the needs of the Resource Adapter function being executed. After return from the call to Interaction.execute(...), the implementer must perform any necessary post-processing to adapt the return Record value (if any) to the shape and/or content defined for this particular data logic method. MOST IMPORTANTLY, indication of certain errors must be converted from how the called function indicates them to the requirements of this interface. Specifically:
        1. Some relational databases throw SQLException to indicate a broken connection if/when you are doing ResultSet.getXXX(). You must catch this exception and rethrow a ResourceException which specifically tells your caller the connection is broken. In this way, users can know that the method failed not due to a logic or datastore error but because the connection failed.
        Parameters:
        interaction - javax.resource.cci.Interaction the interaction this method should call "execute(...)" on
        ispec - javax.resource.cci.InteractionSpec see J2EE Connector spec, CCI
        inputRecord - javax.resource.cci.IndexedRecord see J2EE Connector spec, CCI.This parameter may be null, which indicates there are no input parameters for this function.
        Returns:
        javax.resource.cci.Record see J2EE Connector spec, CCI. Null may be returned.
        Throws:
        javax.resource.ResourceException
      • executeOther

        javax.resource.cci.Record executeOther(javax.resource.cci.Interaction interaction,
                                             javax.resource.cci.InteractionSpec ispec,
                                             javax.resource.cci.IndexedRecord[] inputRecord)
                                               throws javax.resource.ResourceException
        this is the batch executeOther
        Throws:
        javax.resource.ResourceException
      • getConnection

        javax.resource.cci.Connection getConnection(javax.resource.cci.ConnectionFactory connectionFactory,
                                                  AccessIntent accessIntent)
                                                    throws javax.resource.ResourceException
        Using the given ConnectionFactory object, call its "getConnection(javax.resource.cci.ConnectionFactory factory, javax.resource.cci.ConnectionSpec connSpec)" method, creating the ConnectionSpec subclass (if any) designed to work for the given ConnectionFactory subclass. The Connection returned from that method is also returned by this method. See the J2EE Connector (J2C) spec for details on these types. Prior to calling ConnectionFactory.getConnection(...), the implementer may perform any necessary pre-processing to adapt the incoming parameters to the needs of the Resource Adapter being called. After return from the call to the RA, the implementer must perform any necessary post-processing to adapt the return value to this interface. Creation date: (11/5/2001 10:06:22 AM)
        Parameters:
        connectionFactory - javax.resource.cci.ConnectionFactory see J2EE Connector spec, CCI
        accessIntent - com.ibm.ws.ejbpersistence.AccessIntent data class to hold access-intent-related info of potential use by any Resource Adapter. This method uses this parameter to locate a possible cached connection suitable for use with this AccessIntent. If there is no such cached connection, PM obtains one and caches it for future use.
        Returns:
        javax.resource.cci.Connection see J2EE Connector spec, CCI
        Throws:
        javax.resource.ResourceException
      • getNativeConnection

        java.lang.Object getNativeConnection(javax.resource.cci.Connection conn)
        Return the native connection corresponding to the given cci.Connection, or null if there is no "native" connection. For JDBC-based and SQLJ-based Resource Adapters, the returned Object should be of actual type java.sql.Connection.
      • getRecordFactory

        javax.resource.cci.RecordFactory getRecordFactory(javax.resource.cci.ConnectionFactory connectionFactory)
                                                          throws javax.resource.ResourceException
        Return the RecordFactory for the given ConnectionFactory. For Resource Adapters that support ConnectionFactory.getRecordFactory(), this method can simply return the result of that method. Since some (known) Resource Adapters do not support that method on their ConnectionFactory, this method allows you to adapt such RAs for use with PM by adding a RecordFactory of your own devising. PM's requirements on the returned RecordFactory are the same as those defined in the J2C (a.k.a. J2EE Connector) specification. Note that the returned RecordFactory is only used by PM to obtain input Records. This means that, if your implementation of the "executeXXX(...)" methods of this interface can manage with one kind of Record for input regardless of the named function being executed, then the job of writing your own RecordFactory class may be trivial indeed. You can probably get by with e.g., a simple ArrayList subclass which implements the 4 additional methods defined in javax.cci.resource.Record (get/setRecordName, get/setRecordDescription) by merely adding a pair of String instance variables.
        Throws:
        javax.resource.ResourceException
      • getLockType

        int getLockType(javax.resource.cci.ConnectionFactory connectionFactory,
                      AccessIntent accessIntent)
        Return the Lock Type basing on the current backend information and AccessIntent This method returns a value indicating what sort of locking behavior is needed when executing the requested method. The needed locking behavior is deduced from the given AccessIntent object and perhaps from other information, such as specifics about the particular database or datastore vendor being used. This value will be used by the Persistence Manager runtime to find the DataAccessSpec with the matching value. The deploy tool (the tool that generates the code for a particular CMP bean and J2C ResourceAdapter/datastore/backend) generates a BeanAdapterBinding (BAB) class for a particular CMP bean type (see the WebSphere Application Server documentation on writing third-party deploy tools for CMP beans). In the BAB, the deploy tool generated code to create one or more DataAccessSpecs for the different variants of a specific bean method (vary by desired access intent, specific backend, etc). Each DataAccessSpec has an appropriate value set in its locktype field. At runtime, the WebSphere AS runtime will call this method to obtain the desired locking behavior and use it to locate the corresponding DataAccessSpec. The javax.resource.cci.InteractionSpec object held by the DataAccessSpec is passed to the "executeXXX(...)" methods in your EJBToRAAdapter implementation when the time comes to execute the bean method.
      • isBatchSupported

        boolean isBatchSupported(javax.resource.cci.ConnectionFactory connectionFactory,
                               AccessIntent accessIntent)
        Return if batch is supported basing on the current backend information and AccessIntent
      • checkBackendId

        boolean checkBackendId(javax.resource.cci.ConnectionFactory connectionFactory,
                             java.lang.String backendId)
                               throws javax.resource.ResourceException
        Return if currentBackendId is valid for the datasource connection factory connected to .
        Throws:
        javax.resource.ResourceException
      • executeReadReadChecking

        boolean[] executeReadReadChecking(javax.resource.cci.Interaction interaction,
                                        javax.resource.cci.InteractionSpec ispec,
                                        javax.resource.cci.IndexedRecord[] input)
                                          throws javax.ejb.EJBException,
                                                 javax.resource.ResourceException
        Execute read read checking
        Throws:
        javax.ejb.EJBException
        javax.resource.ResourceException
      • getLockType

        int getLockType(javax.resource.cci.ConnectionFactory connectionFactory,
                      AccessIntent accessIntent,
                      java.util.HashMap properties)
        534869 fix: introduce a new parameter: Hashmap properties to adapter class, WSEJBToRAAdapter which implements PM interface EJBToRAAdapter. The HashMap contains the information of the deployed code version. Return the Lock Type basing on the current backend information and AccessIntent This method returns a value indicating what sort of locking behavior is needed when executing the requested method. The needed locking behavior is deduced from the given AccessIntent object and perhaps from other information, such as specifics about the particular database or datastore vendor being used. This value will be used by the Persistence Manager runtime to find the DataAccessSpec with the matching value. The deploy tool (the tool that generates the code for a particular CMP bean and J2C ResourceAdapter/datastore/backend) generates a BeanAdapterBinding (BAB) class for a particular CMP bean type (see the WebSphere Application Server documentation on writing third-party deploy tools for CMP beans). In the BAB, the deploy tool generated code to create one or more DataAccessSpecs for the different variants of a specific bean method (vary by desired access intent, specific backend, etc). Each DataAccessSpec has an appropriate value set in its locktype field. At runtime, the WebSphere AS runtime will call this method to obtain the desired locking behavior and use it to locate the corresponding DataAccessSpec. The javax.resource.cci.InteractionSpec object held by the DataAccessSpec is passed to the "executeXXX(...)" methods in your EJBToRAAdapter implementation when the time comes to execute the bean method.
IBM WebSphere Application ServerTM
Release 8.5