Apple WebObjects 5 - Manual (Page 33)

C H A P T E R 3
Enterprise Objects
WebObjects Support for Enterprise-Object Instances 33

Apple Computer, Inc. January 2002
Locking
WebObjects offers three types of locking: pessimistic, optimistic, and
on-demand. Pessimistic locking uses your database server’s native
locking mechanism to lock rows as they’re fetched and prevents update
conflicts by never allowing two users to look at the same
enterprise-object instance at the same time. Optimistic locking doesn’t
detect update conflicts until you try to save changes to the database; if a
row has changed since it was originally fetched, the save operation is
cancelled. On-demand locking is a mixture of the other two: it locks a
row after you fetch it but before you attempt to modify it. The lock can
fail for one of two reasons: either the row has changed since you fetched
it (optimistic locking), or because someone else already has a lock on the
row (pessimistic locking).
Faulting
When WebObjects fetches a row, it creates enterprise-object instances
representing the destinations of the corresponding entity’s
relationships. By default, WebObjects doesn’t immediately fetch data
for the destination objects of relationships, however. Fetching is fairly
expensive, and further, if WebObjects fetched rows related to the one
explicitly asked for, it would also have to fetch the rows related to those,
and so on, until all of the interrelated rows in the database had been
retrieved. For many applications, this would be a waste of time and
resources. To avoid this, WebObjects creates empty destination objects,
called faults, that fetch their data the first time they’re accessed. This
process, known as faulting, is automatic.
Uniquing
In marrying relational databases to object-oriented programming, one
of the key requirements is that a row in the database be associated with
only one enterprise object in a given context in your application.
WebObjects maintains the mapping of each enterprise-object instance to
its corresponding table row, and uses this information to ensure that,
within a given context, your object set does not include two (possibly
inconsistent) objects for the same row. Uniquing of enterprise-object
instances, as this process is called, reduces memory usage and allows
you to know with confidence that the object you’re interacting with
represents the true state of its associated row as it was last fetched.