RE: Decentralized RDF Distribution

: Danny Ayers:
: The transaction itself shouldn't be too problematic - the relevant part of
: the database made read-only for the duration of the transaction (snapshot
: taken), all (grouped) changes made, read-write reinstated - I see problems
: with queueing where the sequence of the transactions is important, maybe
: better to reject an incoming update (return to sender?) if an update is
: already in progress.
: </out of touch ramblings>
:
: This is obviously quite a crucial problem - does anyone happen know how
: Linda/Javaspaces handles it?

Javaspaces sits atop of Jini which provides a transactions API. It's write and
take operations have a Transaction object parameter. The idea is you request a
Transaction object from a Transaction service provider and place the  javaspaces
operations (which can be distributed) you wish under that Transaction. When
you're done you commit the the Transaction which results in all the operations
inside that Transaction completing. Transactions stops other parties in the
space seeing the Entry (the tuple object in javaspaces). A null value for the
transaction parameter means the operation is in its own scope (entries) are
visible as soon as the operation completes.

This article goes through things clearly:
<http://www.javaworld.com/javaworld/jw-04-2000/jw-0421-jiniology_p.html>:

"When you write an entry into a space under a transaction, the entry is only
seen "within" the transaction until it commits. This means that the entry is
invisible to any client attempting to read, take, or notify it outside of the
transaction. If the entry is taken within the transaction, it will never be seen
outside of the transaction. If the transaction aborts, the entry is discarded.
Once the transaction commits, the entry is available for reads, takes, and
notifications outside of the transaction."


Bill de hOra

Received on Monday, 19 February 2001 14:10:23 UTC