IA371 Persistence and Stateful Failover

1. IA371Persistence and Stateful Failover Evan Ireland EAServer Architect Sybase IAD. Ward Mullins CocoBase Architect Thought Inc.

2. Built-in EAServer Features (Evan) Entity Components Stateful Components Persistence - Component Class, Generated Class, Automatic Persistent State, Java Serialization Storage Component Stateful Failover It’s gotta be fast! CocoBase / EAServer Integration (Ward) Agenda

3. Entity components have a Primary Key and Persistent State, e.g. EJB entity bean. Entity components must have a home interface with findByPrimaryKey. Other finder methods and create methods are optional. All EAServer component types support entity components (C++, COM, Java, PB). Lifecycle of non-EJB entity components is defined by interface CtsComponents::ObjectControl. Property com.sybase.jaguar.component.control Entity Components

4. Stateful components have a globally unique Storage Key (16 byte GUID) and Transient or Persistent State, e.g. EJB stateful session bean. Stateful components with Persistent State must have a home interface with one or more create methods. Finder methods are not permitted. All EAServer component types support stateful components (C++, COM, Java, PB). Lifecycle of non-EJB stateful components with Persistent State is defined by interface CtsComponents::ObjectControl. Property com.sybase.jaguar.component.control. Stateful Components

5. ObjectControl Interface interface ObjectControl { void setObjectContext(in ObjectContext context); void ctsCreate() // return Primary Key for entity raises(::CtsComponents::CreateException); void ctsPostCreate(); void ctsFind() raises(::CtsComponents::FinderException); void ctsActivate(); void ctsLoad(); void ctsStore(); void ctsPassivate(); void ctsRemove() raises(::CtsComponents::RemoveException); void unsetObjectContext(); }; • IDL interface which generalizes javax.ejb.EntityContext and javax.ejb.SessionContext. • ctsCreate… methods are required if home interface contains create methods, ctsPostCreate… methods are required for entity components. • ctsFind… methods are required only for entity components with Component Class Persistence, and only if home interface contains finder methods. • ctsLoad & ctsStore methods usually required for entity components (optional for COM and PB with APS). • Other methods are optional for COM and PB, required for C++ and Java.

6. Should a ShoppingCart component be a stateful component or an entity component? Stateful components with Persistent State allow automatic failover, but client recovery options are limited due to lack of finder methods. Entity components with finder methods allow recovery from client failure and resumable client sessions, e.g. Entity versus Stateful interface ShoppingCartHome { ShoppingCart create(in string user) raises (CtsComponents::CreateException); ShoppingCart findByPrimaryKey(in string user) raises (CtsComponents::FinderException); };

7. Persistence - Component Class • For all component types(C++, COM, Java/EJB, PB),e.g. EJB entity bean with BMP. • The component class handles create / load / store / remove calls and interacts with DBMS. • The generated class can use JDBC, ODBC, CtLib, OCI or delegate to third-party classes (e.g. O/R mapping library) which use one of the above. Server Skeleton (optional) Component Class

8. Persistence - Generated Class • For Java and C++ components, e.g. EJB entity bean with CMP. • A generated class sits between skeleton and component class. • The generated class intercepts create / load / store / remove calls and interacts with DBMS. • The generated class can inherit from or delegate to the component class. • Integration option for O/R mapping tools - EAServer has no CMP code generator. Server Skeleton (required) Generated Class Component Class

9. Automatic Persistent State (APS) • Requires definition of a component’s persistent State (type) and State Methods (getter / setter). • Makes state persistent by dynamic delegation to a Storage Component. • No code generation is required - works with all component models (C++, COM, Java, PB). Server (APS) Skeleton (optional) Component Class

10. Name of a CORBA IDL struct type that represents an object’s persistent state, e.g.“Test::CustomerState”.struct CustomerState{ string name; string address; string phone};For PowerBuilder/PowerJ, the state type is automatically generated during deployment. Or (Java/EJB only) the name of a serializable Java class, e.g. “Test.CustomerState”. State (APS)

11. Names of get/set methods that the server can use to retrieve or update the state of a component instance, e.g. “getState,setState”. State Methods (APS) public class CustomerBean implements EntityBean { ... public CustomerState _state; public void setState(CustomerState state) { _state = state; } public CustomerState getState() { return _state; } ... } • These two methods are all that is required to enable APS. • For strict EJB compliance, Jaguar 3.6+ will allow APS to be used without requiring these methods.

12. Persistence - Java Serialization • Variant of APS for use with EJB stateful session beans requiring failover or passivation. • Ensures that session bean lifecycle conforms with EJB specification. • Uses Java Serialization to generate byte array for storage - resulting data takes more DBMS space than APS with IDL State type. Server Skeleton (required) Component Class (EJB)

13. Performs the actual DBMS interaction. A single storage component can be re-used for storage of many persistent components. Can be written in Java or C++, regardless of the component model used by the persistent components (requires Bind Object option). Built-in Storage Components CtsComponents/JdbcStorage CtsComponents/JdbcStorageReqNew Storage Component

14. “init” - initialize storage component instance. “create” - insert persistent object in DBMS. “find” - check existence of persistent object in DBMS. “load” - retrieve state of persistent object from DBMS. “store” - update state of persistent object in DBMS. “remove” - delete persistent object from DBMS. StorageKey::value and ObjectData::binaryData use GIOP 1.1 CDR format for key and state, with strings encoded in UTF-8. Storage Interface struct StorageKey { BCD::Binary value; }; struct ObjectData { long type; BCD::Binary timestamp; BCD::Binary binaryData; }; interface Storage { void init(in string props); StorageKey create(in StorageKey key, in ObjectData data); boolean find(in StorageKey key); ObjectData load(in StorageKey key); void store(in StorageKey key, in ObjectData data); void remove(in StorageKey key); };

15. EAServer 3.5 Instance data is stored in binary form - GIOP 1.1 CDR format. ASE /ASA - automatic table creation.create table ps_Customer( ps_key binary(16) not null, -- or varbinary/varchar ps_size integer not null, ps_bin1 varbinary(255) null, ps_bin2 varbinary(255) null, ps_bin3 varbinary(255) null, ps_bin4 varbinary(255) null, ps_data image null, primary key (ps_key)) EAServer 3.6+ Arbitrary user-specified field/column mapping. Table (APS) (with J2EE certification - possibly after 3.6 release)

16. EAServer 3.5 findByPrimaryKey only(primarily useful for stateful failover) EAServer 3.6+ arbitrary finder methods with user-specified SQL queries. Finder Methods (APS) (with J2EE certification - possibly after 3.6 release)

17. Use APS for Persistence, or Java Serialization for EJB stateful session bean. Set Automatic failoveroption, set appropriate Transaction Attributes. Consider using an entity component to support recovery after client failure. Select appropriate Storage Component. Stateful Failover

18. EAServer 3.5 Read-Only Methods CocoBase/Javlin Caching(http://www.thoughtinc.com, http://www.exceloncorp.com) EAServer 3.6+ (Gilligan) In-Memory State Replication EAServer 4.0+ (Bali) Object Caching Finder Caching It’s gotta be fast! Note: version numbers for availability of In-Memory State Replication, Object Caching and Finder Caching features are indicative only - contact Product Management to obtain release dates for committed features.

19. Avoid DBMS update(e.g. avoid ejbStore call) at end of transaction for read-only methods. 100% declarative - as opposed to proprietary ‘isModified’ methods in some EJB servers. Can be used with both entity and stateful components. Read-Only Methods

20. Server-to-server replication of instance state. Allows stateful failover without relying on DBMS for persistence. Replication is contained within mirror groups (small groups of servers within a cluster) to avoid scalability problems with large clusters, i.e. you don’t want to replicate state to all cluster members. In-Memory State Replication

21. Distributed in-memory caching of instance state with cluster-wide change notification. Avoid loading state (e.g. ejbLoad) from DBMS by retrieving state from in-memory cache. Use optimistic concurrency control on update to ensure that updates succeed only when the underlying DBMS data has not changed since data was loaded into cache, e.g.update Customer set address = "Wellington", ts = 2 where primaryKey = 123 and ts = 1 Object Caching

22. Caching of the results of entity component finder methods. Avoid running queries (for finder methods)on DBMS by retrieving query results fromin-memory cache. Configurable timeouts for cached results. Automatic invalidation of cached results when underlying data is updated. Finder Caching

23. CocoBase Enterprise O/R O/R Mapping Optimized for EJB andSybase EA Server. Ward Mullins, CTO THOUGHT Inc. www.thoughtinc.com

24. Object to Relational Mapping - Two Examples CocoBase Functionality How CocoBase works Sybase EA Server and CocoBase Optimizations used by the CocoBase Integration Demonstrations of CocoBase with EAServer Presentation Topics www.thoughtinc.com

25. CocoBase Overview www.thoughtinc.com

26. Map from the Object World to Relational Creating an object in the object world adds one or more rows to tables in the relational world Map from Relational World to Object World Performing a database search in Relational world, finds a number of rows, thus creates instances of an object in the Object world. Object to Relational Mapping www.thoughtinc.com

27. Creating a Database Map www.thoughtinc.com

28. CocoBase Maps www.thoughtinc.com

29. DYNAMICALY Maps to all JDBC compliant Relational databases - Create, Edit and Delete Maps - Single or many tables per map and per EJB supported Supports Stored Procedures Automatic & Extensible Java code generation Exports Map repository as XML for runtime or backup Imports existing Java classes to create table and Map Generate Maps and Beans from existing tables User can customize CocoBase via properties files CocoBase Functionality www.thoughtinc.com

30. Automatic code generation of Entity Beans Code generated is based on editable templates User Defined Templates can be added to tool palette Tool and runtime are 100% Java code for portability Current Templates Available for the following; Default Java Objects EJB Servers Supported such as Sybase EA Server Others include BEA Weblogic, Bluestone, Gemstone/J IBM WebSphere, Inprise, Iona, iPlanet, Voyager. CocoBase Functionality www.thoughtinc.com

31. Can import Java Classes for Mapping definitions Creates new RDB tables reflecting Java attributes Generation of maps is aided by Java reflection Relationships are not auto-detected or auto-mapped to relational tables with current release Reflection can auto detect public attributes or private attributes with public get/set methods Supports ‘primitive’, but ‘Object’ attribute types required for database ‘null’ column support CocoBase Functionality www.thoughtinc.com

32. CocoBase Mapping is based on a RDB repository Map from object attributes to columns in many different tables supported RDBMS Repository (4 CBTables for CocoAdmin) - XML Repository (one or many maps per XML file) - XML file can be Jar’d into the deployment jar of the EJB - No need for the CBTables at runtime or production DBs if XML repository is present Objects are dynamically bound to the DB with a Map Mappings can be changed without having to recompile code or redeploy beans How CocoBase Works www.thoughtinc.com

33. Admin Tool is used for; - Defining mapping information - Generating Java classes or EJB’s related to a given map - Generating SQL-Scripts to create a table based on a given bean or Java Class(import) - Generating XML - Repositories for runtime - Can also do same admin tasks from command line or API Small Overhead for Runtime - Plus/Minus 1-5% performance hit over hand coded JDBC - Usually a 30% gain in EJB application performance over hand coded JDBC using pre-optimized code generation How CocoBase Works www.thoughtinc.com

34. CocoBase uses the JDBC Connection Pool from Sybase EA Server. CocoBase doesn’t commit any Transactions. This is done by the Sybase EA Server container entirely. CocoBase can generate EJB (CMP & BMP) Entity Beans from a Map that install into the EA container. Everything that CocoBase generates is template based and therefore customizable. Relationships supported with EJB through Map - one to one, one to many, bean to bean, bean to non-bean Sybase EA Server and CocoBase www.thoughtinc.com

35. CocoBase generates the following for EJB Entity Beans - Remote Interface, Home Interface - Bean Implementation, PK Class Implementation - Descriptors, Manifest file - Properties file for environment info (JDBC Connection) - Make file, batch & shell to compile, to process the descriptor and to jar all the necessary elements into the jar file for the deployment into Sybase. - CMP or BMP Bean with XML descriptor ready to deploy - A developer typically does not have to (re) generate all the files when map changes occur. Sybase EA Server and CocoBase www.thoughtinc.com

36. CocoBase CMP Installer for ‘BMP based CMP’ Once the generic CMP bean is generated from the template or from 3rd party tools, use the CMP Installer Read in the XML descriptor from CocoBase Bean or put in information by hand for the database and pick the Sybase server. CMP Installer checks the bean and subclasses it. Bean is tied to a map in the installation process. Default Finders are created and can be customized. Generate the code, and deployable Jar file. Sybase EA Server and CocoBase CMP www.thoughtinc.com

37. Deploying a CMP Bean with CocoBase www.thoughtinc.com

38. Caching Maps the first time they are accessed - A configuration file defines which maps to cache - When using an XML-repository, maps in the XML file are always cached automatically Fetch caching of Result Sets - ejbFinder ethos return an Enumeration of primary keys - CocoBase caches the result set for later ejbLoad operations - next time an ejbLoad invokes a select, CocoBase gets the data from the temporary fetch cache and not from the RDB - Fetch caching can be turned on or off through Environmentsettings in the descriptor of each Entity Bean Optimizations Used www.thoughtinc.com

39. Methods to get and set the ‘State’ of the bean - Fast access to the state of the Object through state serialization methods and a generated ‘State’ object for each bean. - Objects by Value are transferred to/from client more efficiently Modified flag for detection of changes in the values of the EJB - Update in ejbStore only if necessary by detecting bean changes - Set methods auto-generated to set modified flag - State transfer methods automatically use set/get methods for proper integration with Modified flag (as should coded business methods) Dependent Objects supported - One to One and One to Many relationships of dependent objects - Low Overhead through shared Txn, pooling and serialization... Optimizations Used www.thoughtinc.com

40. Questions Demonstration Summary www.thoughtinc.com