Understanding the Limitations of Causally and Totally Ordered Communication

Understanding the Limitations of Causally and Totally Ordered Communication

Abstract
Causally and totally ordered communication support (CATOCS) has been proposed as important to provide as part of the basic building blocks for constructing reliable distributed systems. In this paper, we identify four major limitations to CATOCS, investigate the applicability of CATOCS to several classes of distributed applications in light of these limitations, and the potential impact of these facilities on communication scalability and robustness. From this investigation, we find limited merit and several potential problems in using CATOCS. The fundamental difficulty with the CN.OCS is that it attempts to solve state problems at the communication level in violation of the well-known “end-to-end” argument.

Семинары продолжаться с 11го мая

Господа
- сегодня(27 апр) семинара не будет
- следующий будет 11 мая, приблизительная тема "Consistency models"

P.S. Всем удачных Майских Праздников, Любви, Шашлыка и Байдарок:)

Concurrency Control, Transaction Isolation and Serializability in SQL92 and Oracle

Concurrency Control, Transaction Isolation and Serializability in SQL92 and Oracle7 - possibly the main document for citation about Oracle-specific levels of tx-isolation:
+ Oracle Consistent Read
+ Snapshot Isolation

P.S. I found it from this post - Generalized Isolation Level Definitions.
"... and Gemstone [22] and Oracle [24] provide serializability and Snapshot Isolation, respectively, using multi-version optimistic implementations."
"...
[24] Oracle Corporation. Concurrency Control, Transaction Isolation and Serializability in SQL92 and Oracle7, July 1995.
..."

Танненбаум, Стеен: Распределенные системы. Принципы и парадигмы

Танненбаум, Стеен: Распределенные системы. Принципы и парадигмы
Содержание:
Глава 1. Введение 22
Глава 2. Связь 81
Глава 3. Процессы 164
Глава 4. Именование 214
Глава 5. Синхронизация 274
Глава 6. Непротиворечивость и репликация 328
Глава 7. Отказоустойчивость 403
Глава 8. Защита 458
Глава 9. Распределенные системы объектов 539
Глава 10. Распределенные файловые системы 623
Глава 11. Распределенные системы документов 699
Глава 12. Распределенные системы согласования 752
Глава 13. Библиография 790
Список терминов 833
Алфавитный указатель 855

Семинар, посвященный масштабируемости высоконагруженных систем

Тут и тут:

Программа мероприятия

1. Данные в высоконагруженных распределённых приложениях. 60 мин (А. Рагозин, Development Manager, Grid Dynamics, г. Москва)
2. Масштабируемость и уровни изоляции транзакций. 30 мин (И. Головач, Senior Software Engineer, Grid Dynamics, г. Харьков)
3. Обработка больших объемов данных с помощью Map/Reduce. 60 мин (А. Клочков, Senior Software Engineer, Grid Dynamics, г. Москва)

The Memory Management Glossary

http://www.memorymanagement.org/glossary/ - big memory management glossary with something about 400 terms.

Glossary articles contains links to The Memory Management Reference Full Bibliography.

Bibliography contains many "strange" articles like this "NREVERSAL of Fortune -- The Thermodynamics of Garbage Collection" [PDF].

Monitors and Concurrent Pascal: a personal history

Monitors and Concurrent Pascal: a personal history (P. Brinch Hansen)
Abstract
This is a personal history of the early development of the monitor concept and its implementation in the programming language Concurrent Pascal. The paper explains how monitors evolved from the ideas of Dahl, Dijkstra, Hoare, and the author (1971-73). At Caltech the author and his students developed and implemented Concurrent Pascal and used it to write several model operating systems (1974-75). A portable implementation of Concurrent Pascal was widely distributed and used for system design (1976-90). The monitor paradigm was also disseminated in survey papers and text books. The author ends the story by expressing his own mixed feelings about monitors and Concurrent Pascal.

[NIO]: Netty

Netty Framework:
The Netty project is an effort to provide an asynchronous event-driven network application framework and tools for rapid development of maintainable high performance & high scalability protocol servers & clients.

Performance Test Reports:

• Performance Comparison of Apache MINA and JBoss Netty Revisited
• Plurk Comet: Handling 100,000+ Concurrent Connections with Netty
• Performance Comparison of Apache MINA and JBoss Netty
• Performance Comparison between NIO Frameworks

1) Last link is a comparision between 5 most popular NIO Frameworks in Java: Netty, Grizzly, MINA, NIO Framework and xSocket.
2) Trustin Lee (founder of Netty)
- have expirience with NIO from 2003
- is co-founder of Apache MINA:)

13 апреля - семинар отменяется

Так выходит, что сегодня я не смогу провести семинар.

Семинар отменяется:(

Тысяча извинений, но сегодня я не смогу провести семинар.

Google Code University Materials

Advanced Concepts in Java

• The Java Memory Model
• Effective Static Race Detection

Distributed Systems

• Tutorials
• Contributed course content
• Hadoop tools and resources
• Video lectures

Some Linux I/O papers

Comparing and Evaluating epoll, select, and poll Event Mechanisms
Abstract
This paper uses a high-performance, eventdriven, HTTP server (the mserver) to compare the performance of the select, poll, and epoll event mechanisms. We subject the mserver to a variety of workloads that allow us to expose the relative strengths and weaknesses of each event mechanism.

NASDAQ+RTJS: 150K tps, 500M tx-per-day

Can't find slides from JavaOne 2007 lecture of Anna Ewing, CIO of the NASDAQ exchange, but here some info about NASDAQ (writed using Real-Time Java Specification (JSR-1)):
- 150K transactions-per-second;
- 500M transactions-per-day.
Here and here.

[DSL]: ApacheCamel

As i wrote early i like some 'specific' style of programming. So now i have yet some examples:

From here:
-------------------------
onException(ValidationException.class).to("activemq:validationFailed");

onException(MyFunctionalException.class).process(new MyFunctionFailureHandler()).stop();

from("jms:queue:order:input")
.to("bean:validateOrder");
.to("bean:transformOrder")
.to("bean:handleOrder");