#5 Require transactional reads on all model elements

[Wyrm Tools]

The platform currently forces the JDO PMF
option "javax.jdo.option.NontransactionalRead"
to "true" in an effort to (prematurely) optimize the
domain model. This behavior has been the root cause
of some hard-to-diagnose bugs (e.g. BUG 1472714). It
also causes some out-of-sync data problems because
the code does not force instances to refresh
themselves from the datastore when necessary. This
has been observed when editing an element (in an
editor), committing the changes, and then viewing the
property pages for the same element -- the property
pages incorrectly see the pre-edit state.

It would be better for us to enforce transactional
read behavior by default and require developers to
enable nontransactional reads when they feel it is
necessary. Therefore, this feature will require that
all platform and d20 model elements be modified to
handle transactional reads. This will require two
major tasks.

1) All element accessors must now throw
ModelException. This will change several interfaces.

2) All element accessor implementations will now have
to wrap the access in a transaction similar to what
mutators must do. It is recommended that a framework
be developed to make this easier on developers,
similar to what was done with the
Element.IPropertyMutator interface and its
corresponding implementation classes.

[Wyrm Tools]

Logged In: YES
user_id=1200066

An attempt was made to implement a subset of the changes
that are required by this FREQ. The task was aborted
after it was determined that the amount of accessor code
that must be wrapped in a transaction was not going to be
addressable in the timeframe before the next minor release.

However, one insight I had while working on this task was
the possibility of moving towards an implementation in
which all elements are detached as they are returned from
the model. This would allow users of elements to not
worry about transactions except when detaching and
reattaching (similar to what is done with the editors).

The drawback of this approach is that there can
potentially be two copies of the same object in memory at
one time (the detached copy and the real element). This
could seriously affect performance. However, if we
require callers to return detached objects to the model,
and destroy the detached copy upon return, there will be
far less of a hit. Namely because the number of "active
detached" elements at any one time is going to be a very
small subset. This idea deserved further consideration
before proceeding to implement this FREQ.