Basic persistence example showing configuration, classes, and client code for a single-table bean.
This example focuses on:
Amber's persistence manages tables in a relational database using a Java bean interface. Each database table corresponds to a single "entity bean". By creating an entity bean with container managed persistence, you let Amber generate the SQL to load, store, and cache entity beans from the database. Avoiding SQL is an advantage in itself, but the primary advantage is the increased flexiblity of your application code. Maintenance and code-refactoring can focus on the beans instead of changing lots of SQL statements in the program.
To find and enhance a persistent Java bean, Amber follows the following procedure.
By the end of initialization time, Amber has enhanced CourseBean and made it available to the application in the persistence-unit "example".
A servlet will then lookup the CourseBean with the following procedure:
With Resin, all the Java source can be dropped in WEB-INF/classes. Resin will automatically compile any changes and regenerate the persistence classes, stubs and skeletons.
Now that we've built the bean, we need to
attach it to Resin. The entity bean is deployed using
the resource.
The persistence.xml lives in META-INF/persistence.xml. Since we're developing in WEB-INF/classes, the file will be in WEB-INF/classes/persistence.xml.
The core of Amber's persistence management is its management of a single table. Much of the work underlying the database management is hidden from the applicaton. Transaction management and caching happen automatically. For example, once the course has been loaded from the database, Amber does not need to query the database again until the course changes. So read-only requests, the most common, can avoid all database traffic.
More complicated applications build on the single table management. The following examples add more realistic features to this example: using queries to find all courses and creating new database rows.