GuidanceOnTheChoicesForPersistence
From SPA Wiki
Contents |
Choices for persistence
File:/GuidanceOnTheChoicesForPersistence1.jpgFile:/GuidanceOnTheChoicesForPersistence2.jpg
This session was a workshop to gather peoples' experiences of persistence mechanisms. The ways that persistence mechanism were chosen and what the issues the persistence mechanisms addressed (or caused) were gathered during the session.
The first part of the session was to gather the mechanisms that the audience had used and to categorize these into groupings of mechanisms. The output of this exercise was:
Mechanism Categories
O/R mechanisms
Entity beans Webshere CMP
O/R Frameworks
Hibernate Toplink Castor JDO
Old O/R
Croeso - Smalltalk thick client %2b CICS/DB2
Pattern Mechanisms
DAO BMP Homebrew JDO Session Beans / PL/SQL
Bespoke
Peer Classes Snap - C Generator Homebrew in C%2b%2b
Language Mechanisms
Framework - Serialization/Streaming Serialization/XML Java Serialization
Object Dbs
Gemstone Object Store
Note: There was no experience of Ruby on Rails, any .NET frameworks or Object/Relational database extensions
Choosing a mechanism
The audience took part in an exercise to consider the ways that the categories of persistence mechanisms were chosen.
O/R Mechanisms
Fashion CV ware
O/R Framework
No DB Query Experience Thought would increase productivity Proof of Concept Developer's lunch Cost (Developement %2b Deployment) Performance Standards based Fashion Supportability
O/R Mechanism
Bundled with toolset (it was there)
Old O/R
IT directors Whim
Object DB
Purity - the right way (at the time) resume%2b%2b
Language Mechanisms
Availability in language Didn't think needed query language Pure persistence (identity not needed) Experience
Patterns Mechanisms
Couldn't use O/R Frameworks but didn't want to start from scratch Experience
Bespoke
Nothing else available Someone wanted to build one
Object Dbs
Availability of Resources
Some mechanisms were chosen as a result of failures of others, in a trial, error, trial, error cycle, the examples given were
EJB->DAO->Hibernate Homebrew->Castor/JDO->'real' JDO
Sucesses and Failures using the persistence mechanisms
The audience took part in an exercise to consider where mechanisms were sucessful and where they failed.
O/R mapping
kept Data Definition in one place simplified Data Definition process
Patterns
BMP worked because it was handwritten by an expert
Lang Mechanism
Used XML serialization for message passing succefully Used serialization to Blobs in a database, but as the software developed more attribute value pairs where added as columns.
Object DB
Worked with fluid schema and dynamic class/object models Highly paid experts and high cost technology were difficulties Good because did not need to do any O/R mapping Performance of Object Databases are slow, though these are improving No (impact) on change
Bespoke %2b Homegrown
Used because nothing else was available to do the job Was the most flexible Was slow to develop app developers saw this as an intersting problem Was expensive to develop Was high risk Was cheap to deploy External skills were a problem (knowledge internal only) Perfromance was better in some cases but worse in others
O/R Mechanisms
Early versions were naïve and limited (no associations) The performance was a problem Help to manage transactions across non-DB resources Security infrastruture helped It became unfashionable, so harder to get knowledable staff
O/R Frameworks
Started with EJBs moved to Hibernate/Spring which worked Cost of deployment was low for hibernate Performance was good Flexibility was a problem for certain types of object model Availability of trained resources is good for hibernate
Summary
The audience concluded that the O/R Frameworks such as Hibernate were the best chance of success as the persistence mechanism. They noted however that it does not solve all the problems and that if the system requires support not provided by the O/R Frameworks (for example fluid schemas or complex security infrastructures) then something else has to be considered. In that case the most common factors for selection were experience or fashion. In summary there was no one solution that worked for everyone.
