Because Ubik loads many objects on demand, it is
possible that an inconsistent subset of the object model might be
created on the client. Two related objects with a particular
constraint on their relationship may have this constraint broken if
one is loaded, and the other is changed significantly before it is
This issue is also present in most relational
databases under their default isolation settings, which are either
'Read Committed' or 'Repeatable Read.' Databases, however, provide
the 'Serialisable' isolation level for transactions that absolutely
must be isolated. This situation is probably rare enough that it
doesn't warrant major attention, however it would be a worthwhile
addition to Ubik.
Without access to the underlying database
connection, it is difficult for Ubik to provide this isolation level.
One solution is to allow clients to instigate
long-running server-side transactions, which could be applied only
when absolutely necessary. There are many issues with this although
they can be worked around to a reasonable degree. Added complexity to
what is currently a very simple system is the main drawback.
Another solution is to provide a command
interface to the server, through which serialised command objects can
be executed in a server-side application domain, within a
serialisable transaction. This approach places more design
constraints on the application but given that it is for one-off cases
this may be acceptable.
As more alternatives develop they'll be listed