Mutual Exclusion In JavaSpaces

Posted by: Joseph Ottinger on ?? 15, 2007 DIGG
function _parseDiggURL() {
var _diggURL = "http://digg.com/submit?phase=2&topic=Programming&url="
_diggURL += encodeURIComponent(location.href);
_diggURL += "&title=";
_diggURL += escape ( "Mutual Exclusion In JavaSpaces") ;
_diggURL += "&bodytext=";
_diggURL += escape ( "Lorenzo Puccetti has written "Mutual Exclusion In JavaSpaces," which attempts to start a trend in discussion of common patterns for space-based architecture. The pattern presented is, obviously, mutual exclusion - similar to synchronized blocks for regular Java code.

The pattern discussion itself is fairly interesting: one solution is to take the space entry from the space, replacing the entry when the local processing is done. However, if the local processing fails, then the space won't magically get the entry back.

The next step is to repair that by using transactions in the space; if the transaction leasetime expires, then the entry is released and other processes can access it as if nothing has happened.

He closes the discussion of the pattern by pointing out that the "as if nothing has happened" phrase is incorrect - after all, the lease time will have expired, which means time has passed. This can lead to resource starvation, unless your architecture properly compensates for it.

That compensation mechanism isn't gone into by Mr. Puccetti; what techniques would you suggest for compensating for multiple requests for a single element? (After all, this is appropriate beyond space-based architectures; consider java.util.concurrency's Latch mechanism, for example.)

Also... what other patterns would you like to point out regarding space-based architectures?").substring(0,300);
return _diggURL ;
}
Lorenzo Puccetti has written "Mutual Exclusion In JavaSpaces," which attempts to start a trend in discussion of common patterns for space-based architecture. The pattern presented is, obviously, mutual exclusion - similar to synchronized blocks for regular Java code.The pattern discussion itself is fairly interesting: one solution is to take the space entry from the space, replacing the entry when the local processing is done. However, if the local processing fails, then the space won't magically get the entry back.The next step is to repair that by using transactions in the space; if the transaction leasetime expires, then the entry is released and other processes can access it as if nothing has happened.He closes the discussion of the pattern by pointing out that the "as if nothing has happened" phrase is incorrect - after all, the lease time will have expired, which means time has passed. This can lead to resource starvation, unless your architecture properly compensates for it.That compensation mechanism isn't gone into by Mr. Puccetti; what techniques would you suggest for compensating for multiple requests for a single element? (After all, this is appropriate beyond space-based architectures; consider java.util.concurrency's Latch mechanism, for example.)Also... what other patterns would you like to point out regarding space-based architectures?
Threaded replies
·
Mutual Exclusion In JavaSpaces by Joseph Ottinger on Tue May 15 07:49:04 EDT 2007
·
Re: Mutual Exclusion In JavaSpaces by John Nichol on Tue May 15 10:04:11 EDT 2007
·
Resolving the LeaseTime expiration issue by Owen Taylor on Tue May 15 10:00:50 EDT 2007
·
Re: Mutual Exclusion In JavaSpaces by Guido Anzuoni on Tue May 15 10:24:50 EDT 2007
·
Re: Mutual Exclusion In JavaSpaces by Cameron Purdy on Tue May 15 10:33:42 EDT 2007
·
Re: Mutual Exclusion In JavaSpaces by Owen Taylor on Tue May 15 11:58:41 EDT 2007
·
Re: Mutual Exclusion In JavaSpaces by Cameron Purdy on Tue May 15 12:00:59 EDT 2007