Чому так багато програмістів абсолютно ненавидять шари поширеності об'єктів?

Поширеність - це проста техніка надання властивостей ACID об'єктній моделі пам'яті на основі двійкової серіалізації та ведення журналу запису наперед. Це працює так:

• Почніть з знімка. Серіалізуйте об'єктну модель і запишіть її у файл.
• Створіть файл журналу. Для кожного виклику в об'єктній моделі серіалізуйте виклик та його аргументи.
• Коли журнал стає занадто великим, ви закриваєтесь, або якщо це інакше зручно, виконайте контрольну точку: напишіть новий знімок і обріжте журнал.
• Щоб відмовитись або відновитись після аварії або енергетичного удару, завантажте останній знімок і повторно виконайте всі дзвінки, записані в журналі.

Заходи безпеки, необхідні для цієї роботи, є:

• Не дозволяйте посиланням, що змінюються, уникати або входити в шар поширеності. Вам потрібна якась схема проксі або OID, як якщо б ви робили RPC. (Це така поширена помилка для новачків, яку прозвали " проблемою хрещення ".)
• Вся логіка, доступна під час виклику, повинна бути повністю детермінованою і не повинна виконувати значущі для бізнес-логіки виклики вводу / виводу або ОС. Запис у журнал діагностики, ймовірно, добре, але отримати системний час або запустити асинхронний делегат, як правило, це не так. Це так, що журнал відтворюється однаково, навіть якщо він відновлений на іншій машині або в інший час. (Більшість кодів поширеності забезпечує альтернативний виклик часу для отримання часової позначки транзакції.)
• Паралельність письменника вносить неоднозначність у тлумачення журналу, тому це заборонено.

Це тому, що ...

• люди розробили для них поганий смак, намагаючись використати його в проекті, який не підходив ^* до нього?
• Жорстока пропаганда Клауса Вустефельда відключила людей ?
• люди, яким подобається імперативна модель програмування, не люблять відокремлювати введення-виведення від обчислення , вважаючи за краще замішати обчислення з вводу-виводу та виклику потоків?
• Шари поширеності настільки концептуально прості та настільки тісно пов'язані з характеристиками рамки, яку вони мешкають, що вони, як правило, розроблені на замовлення для проекту, що робить їх занадто чужими / нестандартними / ризикованими?
• просто важко тримати прямо, що треба бути обережним, щоб цього не робити?
• голови новачків просто здаються вибухають, стикаючись з чимось таким, що не є таким самим двоярусним додатком, керованим базами даних, якого вони навчились писати в школі? ;)

^* У всьому наборі даних уміщається в оперативній пам'яті , вам не потрібен письменник паралелізм, і вам не потрібно робити спеціальні запити, звіти або експорт в сховище даних. З вибаченнями у SQLite, поширеність - це поліпшення збереження файлів, а не заміна Oracle.

Я думаю, що проблема полягає в тому, що вони мають ДУЖЕ специфічний випадок використання (ваша невідповідна причина). Я будував і працював над системами, які використовують такий підхід, і коли у вас є проблема, яка насправді ця проблема, це може бути прекрасним рішенням.

Інша частина полягає в тому, що це дуже схоже на деякі більш болючі біти користувацького зберігання даних, які ви знаходили багато 10+ років тому і має ті самі підводні камені (думаю, що пакет оновлений btreive, наприклад), який приносить ваш "занадто замовний" пункт, але також ускладнює пошук частин полиці, які ввічливо працюють з нею.

Остання частина полягає в тому, що їх можна прокляти у багатьох випадках, і люди взагалі досить звикли до того, що зараз можуть отримати свої відповіді.

Я думаю, вам спочатку потрібно продемонструвати, що так багато розробників абсолютно їх ненавидять. Я не думаю, що це так. Вважайте, що пташиний птах, якийсь час повернувся, формалізував тут подібний зразок .

Відповідь на питання полягає в тому, що поки теорія проста, практика не є.

Тільки для тестування такої установки потрібні десятки тестових випадків, додавання в mutli-процес або багатопотоковий код, і це переходить до сотень можливих умов, які потрібно перевірити, як для стійкості, так і для відновлення.

Будь-який монітор транзакцій, такий як CICS, Tuxedo, Weblogic, Websphere, JBOSS або .NET, забезпечить усі ці засоби в чистому та перевіреному порядку. І будь-яка база даних забезпечить "достатню" транзакційну / стійкість для більшості програм.

В основному справа з цим колесом була винайдена і вдосконалена давно.

Необхідні реквізити звучать трохи важко для кодування, особливо для більшості систем, які не потребують відповідності ACID під час роботи в пам'яті. Накладні звуки теж трохи неприємні - там є багато державних стежок.