Java Reference
In-Depth Information
"Required"
/>
in your Blueprint enough to ensure complete transactional integrity?
Aren't you better off keeping the transactions where you can see them?
The answers to these questions are, respectively, “not totally” and “almost never.”
There will be applications where you'll have to think a bit harder about what's going
on with your transactions, but there will be few occasions indeed where this extends to
having to code the transactions by hand.
Let's explore an example where the minimal transaction support isn't enough. So
far, Fancy Foods has been a bit more like a printed flier than a modern shopping website.
(And if it was a flier for your business, you'd probably fire the graphic designer respon-
sible.) Users can see some of the available food, but they can't buy the food. Profits will
be higher if people can buy things!
Customer
Name
CreditLimit
Balance
Food
Name
Price
QuantityInStock
ENABLING FOOD SHOPPING
A
fancyfoods.foods.Customer
interface
should be added to the
API
bundle, and a
fancyfoods.persistence.CustomerImpl
implementation class written. As with
Food-
Impl
, the
@Entity
annotation should be
added and a primary key declared:
Figure 3.11
The schema for the purchase-en-
abled Fancy Foods website. The schema is still
simple, but there are now two entities, and two
corresponding tables in the database.
@Entity
public class CustomerImpl implements Customer {
@Id
private String name;
private double creditLimit;
private double balance;
[. . .]
If you're using a version of Aries persistence below 0.4, the new entity class needs to be
listed in the persistence.xml so that it can be managed by
JPA
:
<class>fancyfoods.persistence.CustomerImpl</class>
We'll also add an
Accounting
interface and implementation to handle retrieving and
updating customer details. Like the
InventoryImpl
, the
AccountingImpl
should be
managed by Blueprint and exposed as a service:
<bean
id="accounting"
class="fancyfoods.persistence.AccountingImpl">
<tx:transaction method="*" value="Required" />
<jpa:context property="entityManager" unitname="fancyfoods" />
</bean>
<service
interface="fancyfoods.food.Accounting"
ref="accounting" />
The
EntityManager
gets injected into the
AccountingImpl
, which makes handling
the persistence easy. The
AccountingImpl
will do something we haven't done yet,
which is to make changes to entity classes and persist them back.
