ООDB на основе Pharo

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
51 messages Options
123
Reply | Threaded
Open this post in threaded view
|

ООDB на основе Pharo

Dennis Schetinin
… Раз пошла такая пьянка, подниму-ка и я один вопрос.

Можно ли на основе Pharo сделать нормальную объектную базу — по типу GemStone? И, если да, что для этого надо?

…И маленький со-вопросик: а какие еще ОБД реально существуют? Гуглить и википедировать я умею, поэтому вопрос именно про реальность: может, кто-то сталкивался на практике? Насколько с ними все хорошо/плохо?

--

Best regards,


Dennis Schetinin

--
--
http://groups.google.ru/group/sugr
---
Вы получили это сообщение, поскольку подписаны на группу "Russian Smalltalk User Group".
Чтобы отменить подписку на эту группу и больше не получать от нее сообщения, отправьте письмо на электронный адрес [hidden email].
Чтобы настроить другие параметры, перейдите по ссылке https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: ООDB на основе Pharo

Nikolay Kleptsov
Что имеем на сегодняшний день?

Сравнение буду делать с Фаро, как наиболее знакомая из Smalltalk систем.
Pharo
размер образа в ОЗУ - до 500 мб (можно и больше)
размер внешней памяти - равен образу или почти
сохранение - весь образ, причем во время сохранения, образ как бы останавливается во времени
наличие логики - да. для логики не критично частое сохранение
сборка мусора - да и обязательная

БД MongoDb
Размер в ОЗУ - определяется нагрузкой и настройками
Размер внешней памяти - неограничен, конечно все в пределах размера диска
Сохранение - 1 документ (запись)
Наличие логики - есть (минимально), в основном для поиска, можно добавлять javascript код
сборка мусора - нет необходимости
Также у MongoDb по сравнению с реляционными БД в документ можно записывать произвольные поля, формат данных json.

Получается для Pharo сохранение данных для продакшн невозможно. Объем данных в пределах одного образа. сохраняются данные вместе с образом. Сохранение одного объекта в стандартной конфигурации невозможно. К пюсам стоит отнести возможность динамического изменения логики и отладки (инструментарий мощный). Для данных (объекты) возможно создание кеша 200-400 мб и обработка их.

MongoDb может хранить огромные объемы данных, выборка по индексу для коллекции. Запись отдельными документами, кеш в памяти ускоряет доступ к часто используемым документам, логика есть но отладка и создание сложнее чем в фаро.

На сегодня Pharo может выступать как кеш объектов и логика модели, сохранение данных только с помощью внешних приложений, Еще веб доступ к кешированным объектам

2 декабря 2014 г., 19:04 пользователь Dennis Schetinin <[hidden email]> написал:
… Раз пошла такая пьянка, подниму-ка и я один вопрос.

Можно ли на основе Pharo сделать нормальную объектную базу — по типу GemStone? И, если да, что для этого надо?

…И маленький со-вопросик: а какие еще ОБД реально существуют? Гуглить и википедировать я умею, поэтому вопрос именно про реальность: может, кто-то сталкивался на практике? Насколько с ними все хорошо/плохо?

--

Best regards,


Dennis Schetinin

--
--
http://groups.google.ru/group/sugr
---
Вы получили это сообщение, поскольку подписаны на группу "Russian Smalltalk User Group".
Чтобы отменить подписку на эту группу и больше не получать от нее сообщения, отправьте письмо на электронный адрес [hidden email].
Чтобы настроить другие параметры, перейдите по ссылке https://groups.google.com/d/optout.

--
--
http://groups.google.ru/group/sugr
---
Вы получили это сообщение, поскольку подписаны на группу "Russian Smalltalk User Group".
Чтобы отменить подписку на эту группу и больше не получать от нее сообщения, отправьте письмо на электронный адрес [hidden email].
Чтобы настроить другие параметры, перейдите по ссылке https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: ООDB на основе Pharo

Nikolay Kleptsov
In reply to this post by Dennis Schetinin
Объектную базу на Smalltalk можно сделать только с помощью внешних приложений (БД). Несколько десятков образов (логика, кеш), которые синхронизированы или настроенны на самосинхронизацию. Может получится довольно мощная объектная база + логика.
Все-таки комментарий Александра Когана прояснил бы ситуацию

2 декабря 2014 г., 19:04 пользователь Dennis Schetinin <[hidden email]> написал:
… Раз пошла такая пьянка, подниму-ка и я один вопрос.

Можно ли на основе Pharo сделать нормальную объектную базу — по типу GemStone? И, если да, что для этого надо?

…И маленький со-вопросик: а какие еще ОБД реально существуют? Гуглить и википедировать я умею, поэтому вопрос именно про реальность: может, кто-то сталкивался на практике? Насколько с ними все хорошо/плохо?

--

Best regards,


Dennis Schetinin

--
--
http://groups.google.ru/group/sugr
---
Вы получили это сообщение, поскольку подписаны на группу "Russian Smalltalk User Group".
Чтобы отменить подписку на эту группу и больше не получать от нее сообщения, отправьте письмо на электронный адрес [hidden email].
Чтобы настроить другие параметры, перейдите по ссылке https://groups.google.com/d/optout.

--
--
http://groups.google.ru/group/sugr
---
Вы получили это сообщение, поскольку подписаны на группу "Russian Smalltalk User Group".
Чтобы отменить подписку на эту группу и больше не получать от нее сообщения, отправьте письмо на электронный адрес [hidden email].
Чтобы настроить другие параметры, перейдите по ссылке https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: ООDB на основе Pharo

Denis Kudriashov
In reply to this post by Nikolay Kleptsov

2 декабря 2014 г., 17:33 пользователь Nikolay Kleptsov <[hidden email]> написал:
БД MongoDb


Все таки Монго не объектная БД. Есть большая разница между документо-ориентированными и объектными БД. И, на мой взгляд, к NoSQL-базам не относят OODB. По крайней мере, ни в каких статьях по NoSQL я не видел упоминание OODB.

Главное отличие NoSQL от OODB - как они смотрят на взаимосвязи между объектами. Например, в Монго, если у вас один документ ссылается на другой, при удалении последнего в оригинальном документе останется невалидная ссылка. В объектной базе такое невозможно. Если вы удалите объект из некоторой коллекции-реестра, он никуда не денется из других объектов, которые на него ссылаются.
Я бы сказал, суть OODB именно в том, что данные в них организованы в виде объектов как в обычной объектной программе. То, что я видел среди NoSQL, таким свойством не обладает (MongoDB точно).

Среди OODB сильно выделяется Gemstone. Это уже не "тупое" хранилище данных, а полноценный смолтолк. Можно его воспринимать как многопользовательский имидж с транзакционной памятью. Сохранение имиджа в нем является коммитом транзакции (Smalltalk commitChanges). Кстати, на жемстоуне работают огромные коммерческие системы, в которых живут триллионы объектов (сотни терабайтов).


--
--
http://groups.google.ru/group/sugr
---
Вы получили это сообщение, поскольку подписаны на группу "Russian Smalltalk User Group".
Чтобы отменить подписку на эту группу и больше не получать от нее сообщения, отправьте письмо на электронный адрес [hidden email].
Чтобы настроить другие параметры, перейдите по ссылке https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: ООDB на основе Pharo

Denis Kudriashov
In reply to this post by Dennis Schetinin
Если не по типу жемстоуна, а просто как хранилище, то такое уже есть: Magma. Возможно, сейчас она не слишком дружит с фарой , но, думаю, портировать со сквика не такая большая проблема.



2 декабря 2014 г., 16:04 пользователь Dennis Schetinin <[hidden email]> написал:
… Раз пошла такая пьянка, подниму-ка и я один вопрос.

Можно ли на основе Pharo сделать нормальную объектную базу — по типу GemStone? И, если да, что для этого надо?

…И маленький со-вопросик: а какие еще ОБД реально существуют? Гуглить и википедировать я умею, поэтому вопрос именно про реальность: может, кто-то сталкивался на практике? Насколько с ними все хорошо/плохо?

--

Best regards,


Dennis Schetinin

--
--
http://groups.google.ru/group/sugr
---
Вы получили это сообщение, поскольку подписаны на группу "Russian Smalltalk User Group".
Чтобы отменить подписку на эту группу и больше не получать от нее сообщения, отправьте письмо на электронный адрес [hidden email].
Чтобы настроить другие параметры, перейдите по ссылке https://groups.google.com/d/optout.

--
--
http://groups.google.ru/group/sugr
---
Вы получили это сообщение, поскольку подписаны на группу "Russian Smalltalk User Group".
Чтобы отменить подписку на эту группу и больше не получать от нее сообщения, отправьте письмо на электронный адрес [hidden email].
Чтобы настроить другие параметры, перейдите по ссылке https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: ООDB на основе Pharo

Denis Kudriashov
In reply to this post by Nikolay Kleptsov

2 декабря 2014 г., 18:04 пользователь Nikolay Kleptsov <[hidden email]> написал:
Объектную базу на Smalltalk можно сделать только с помощью внешних приложений (БД). Несколько десятков образов (логика, кеш), которые синхронизированы или настроенны на самосинхронизацию. Может получится довольно мощная объектная база + логика.
Все-таки комментарий Александра Когана прояснил бы ситуацию


Как я писал выше, Gemstone существует и успешно применяется в очень крупных и высоконагруженных системах.

--
--
http://groups.google.ru/group/sugr
---
Вы получили это сообщение, поскольку подписаны на группу "Russian Smalltalk User Group".
Чтобы отменить подписку на эту группу и больше не получать от нее сообщения, отправьте письмо на электронный адрес [hidden email].
Чтобы настроить другие параметры, перейдите по ссылке https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: ООDB на основе Pharo

Nikolay Kleptsov
In reply to this post by Denis Kudriashov
Я не указывал, что MongoDb объектная база, только сравнивал Pharo с одной из баз данных, в данном случае MongoDb

2 декабря 2014 г., 21:51 пользователь Denis Kudriashov <[hidden email]> написал:

2 декабря 2014 г., 17:33 пользователь Nikolay Kleptsov <[hidden email]> написал:
БД MongoDb


Все таки Монго не объектная БД. Есть большая разница между документо-ориентированными и объектными БД. И, на мой взгляд, к NoSQL-базам не относят OODB. По крайней мере, ни в каких статьях по NoSQL я не видел упоминание OODB.

Главное отличие NoSQL от OODB - как они смотрят на взаимосвязи между объектами. Например, в Монго, если у вас один документ ссылается на другой, при удалении последнего в оригинальном документе останется невалидная ссылка. В объектной базе такое невозможно. Если вы удалите объект из некоторой коллекции-реестра, он никуда не денется из других объектов, которые на него ссылаются.
Я бы сказал, суть OODB именно в том, что данные в них организованы в виде объектов как в обычной объектной программе. То, что я видел среди NoSQL, таким свойством не обладает (MongoDB точно).

Среди OODB сильно выделяется Gemstone. Это уже не "тупое" хранилище данных, а полноценный смолтолк. Можно его воспринимать как многопользовательский имидж с транзакционной памятью. Сохранение имиджа в нем является коммитом транзакции (Smalltalk commitChanges). Кстати, на жемстоуне работают огромные коммерческие системы, в которых живут триллионы объектов (сотни терабайтов).


--
--
http://groups.google.ru/group/sugr
---
Вы получили это сообщение, поскольку подписаны на группу "Russian Smalltalk User Group".
Чтобы отменить подписку на эту группу и больше не получать от нее сообщения, отправьте письмо на электронный адрес [hidden email].
Чтобы настроить другие параметры, перейдите по ссылке https://groups.google.com/d/optout.

--
--
http://groups.google.ru/group/sugr
---
Вы получили это сообщение, поскольку подписаны на группу "Russian Smalltalk User Group".
Чтобы отменить подписку на эту группу и больше не получать от нее сообщения, отправьте письмо на электронный адрес [hidden email].
Чтобы настроить другие параметры, перейдите по ссылке https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: ООDB на основе Pharo

Dennis Schetinin
In reply to this post by Denis Kudriashov
Я именно про GemStone, разумеется. Других настоящих ОБД я и не знаю, если честно.

Речь про то, чтобы сделать такой фреймворк, загрузка которого в Pharo превращала бы его в объектную базу данных со всеми фишками (ACID, пользователи) с максимально "прозрачностью" — чтобы написанное без БД приложение при загрузки этой библиотеки "автоматически" (без изменения кода) получало бы все эти вкусности… 

Что этому с технической т.з. мешает?



--

Best regards,


Dennis Schetinin


2 декабря 2014 г., 19:54 пользователь Denis Kudriashov <[hidden email]> написал:
Если не по типу жемстоуна, а просто как хранилище, то такое уже есть: Magma. Возможно, сейчас она не слишком дружит с фарой , но, думаю, портировать со сквика не такая большая проблема.



2 декабря 2014 г., 16:04 пользователь Dennis Schetinin <[hidden email]> написал:
… Раз пошла такая пьянка, подниму-ка и я один вопрос.

Можно ли на основе Pharo сделать нормальную объектную базу — по типу GemStone? И, если да, что для этого надо?

…И маленький со-вопросик: а какие еще ОБД реально существуют? Гуглить и википедировать я умею, поэтому вопрос именно про реальность: может, кто-то сталкивался на практике? Насколько с ними все хорошо/плохо?

--

Best regards,


Dennis Schetinin

--
--
http://groups.google.ru/group/sugr
---
Вы получили это сообщение, поскольку подписаны на группу "Russian Smalltalk User Group".
Чтобы отменить подписку на эту группу и больше не получать от нее сообщения, отправьте письмо на электронный адрес [hidden email].
Чтобы настроить другие параметры, перейдите по ссылке https://groups.google.com/d/optout.

--
--
http://groups.google.ru/group/sugr
---
Вы получили это сообщение, поскольку подписаны на группу "Russian Smalltalk User Group".
Чтобы отменить подписку на эту группу и больше не получать от нее сообщения, отправьте письмо на электронный адрес [hidden email].
Чтобы настроить другие параметры, перейдите по ссылке https://groups.google.com/d/optout.

--
--
http://groups.google.ru/group/sugr
---
Вы получили это сообщение, поскольку подписаны на группу "Russian Smalltalk User Group".
Чтобы отменить подписку на эту группу и больше не получать от нее сообщения, отправьте письмо на электронный адрес [hidden email].
Чтобы настроить другие параметры, перейдите по ссылке https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: ООDB на основе Pharo

Nikolay Kleptsov
Хорошо, имеется Pharo образ или несколько, где хранить данные (объекты)? Каким образом? У Фаро все объекты в памяти, сохранять целый образ из-за одного измененного объекта целесообразно?

2 декабря 2014 г., 22:34 пользователь Dennis Schetinin <[hidden email]> написал:
Я именно про GemStone, разумеется. Других настоящих ОБД я и не знаю, если честно.

Речь про то, чтобы сделать такой фреймворк, загрузка которого в Pharo превращала бы его в объектную базу данных со всеми фишками (ACID, пользователи) с максимально "прозрачностью" — чтобы написанное без БД приложение при загрузки этой библиотеки "автоматически" (без изменения кода) получало бы все эти вкусности… 

Что этому с технической т.з. мешает?



--

Best regards,


Dennis Schetinin


2 декабря 2014 г., 19:54 пользователь Denis Kudriashov <[hidden email]> написал:

Если не по типу жемстоуна, а просто как хранилище, то такое уже есть: Magma. Возможно, сейчас она не слишком дружит с фарой , но, думаю, портировать со сквика не такая большая проблема.



2 декабря 2014 г., 16:04 пользователь Dennis Schetinin <[hidden email]> написал:
… Раз пошла такая пьянка, подниму-ка и я один вопрос.

Можно ли на основе Pharo сделать нормальную объектную базу — по типу GemStone? И, если да, что для этого надо?

…И маленький со-вопросик: а какие еще ОБД реально существуют? Гуглить и википедировать я умею, поэтому вопрос именно про реальность: может, кто-то сталкивался на практике? Насколько с ними все хорошо/плохо?

--

Best regards,


Dennis Schetinin

--
--
http://groups.google.ru/group/sugr
---
Вы получили это сообщение, поскольку подписаны на группу "Russian Smalltalk User Group".
Чтобы отменить подписку на эту группу и больше не получать от нее сообщения, отправьте письмо на электронный адрес [hidden email].
Чтобы настроить другие параметры, перейдите по ссылке https://groups.google.com/d/optout.

--
--
http://groups.google.ru/group/sugr
---
Вы получили это сообщение, поскольку подписаны на группу "Russian Smalltalk User Group".
Чтобы отменить подписку на эту группу и больше не получать от нее сообщения, отправьте письмо на электронный адрес [hidden email].
Чтобы настроить другие параметры, перейдите по ссылке https://groups.google.com/d/optout.

--
--
http://groups.google.ru/group/sugr
---
Вы получили это сообщение, поскольку подписаны на группу "Russian Smalltalk User Group".
Чтобы отменить подписку на эту группу и больше не получать от нее сообщения, отправьте письмо на электронный адрес [hidden email].
Чтобы настроить другие параметры, перейдите по ссылке https://groups.google.com/d/optout.

--
--
http://groups.google.ru/group/sugr
---
Вы получили это сообщение, поскольку подписаны на группу "Russian Smalltalk User Group".
Чтобы отменить подписку на эту группу и больше не получать от нее сообщения, отправьте письмо на электронный адрес [hidden email].
Чтобы настроить другие параметры, перейдите по ссылке https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: ООDB на основе Pharo

Nikolay Kleptsov
In reply to this post by Dennis Schetinin



Речь про то, чтобы сделать такой фреймворк, загрузка которого в Pharo превращала бы его в объектную базу данных со всеми фишками (ACID, пользователи) с максимально "прозрачностью" — чтобы написанное без БД приложение при загрузки этой библиотеки "автоматически" (без изменения кода) получало бы все эти вкусности… 

Зачем изобретать велосипед, если все как в GemStone, тогда и использовать GemStone

--
--
http://groups.google.ru/group/sugr
---
Вы получили это сообщение, поскольку подписаны на группу "Russian Smalltalk User Group".
Чтобы отменить подписку на эту группу и больше не получать от нее сообщения, отправьте письмо на электронный адрес [hidden email].
Чтобы настроить другие параметры, перейдите по ссылке https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: ООDB на основе Pharo

Denis Kudriashov

2 декабря 2014 г., 20:10 пользователь Nikolay Kleptsov <[hidden email]> написал:
Зачем изобретать велосипед, если все как в GemStone, тогда и использовать GemStone

Например, потому что он платный и не opensource. (Бесплатная версия есть, но с ограничениями)

--
--
http://groups.google.ru/group/sugr
---
Вы получили это сообщение, поскольку подписаны на группу "Russian Smalltalk User Group".
Чтобы отменить подписку на эту группу и больше не получать от нее сообщения, отправьте письмо на электронный адрес [hidden email].
Чтобы настроить другие параметры, перейдите по ссылке https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: ООDB на основе Pharo

Denis Kudriashov
In reply to this post by Dennis Schetinin

2 декабря 2014 г., 19:34 пользователь Dennis Schetinin <[hidden email]> написал:
Я именно про GemStone, разумеется. Других настоящих ОБД я и не знаю, если честно.

Речь про то, чтобы сделать такой фреймворк, загрузка которого в Pharo превращала бы его в объектную базу данных со всеми фишками (ACID, пользователи) с максимально "прозрачностью" — чтобы написанное без БД приложение при загрузки этой библиотеки "автоматически" (без изменения кода) получало бы все эти вкусности… 

Что этому с технической т.з. мешает?

Здесь виртуалка должна быть специальная. Образ должен грузится в разделяемую виртуальную память и много чего из этого следует.
Такое наверно может быть возможно только в системах типа BeeSmalltalk или Mist. В них абсолютно все написано на смолотоке и изменяемо динамически, включая GC, JIT и так далее, и различные реализации этих компонент могли бы загружается в виде "пакетов". Но как и сами эти системы, "подгрузка жемстоун способностей" выглядит невероятно :)

--
--
http://groups.google.ru/group/sugr
---
Вы получили это сообщение, поскольку подписаны на группу "Russian Smalltalk User Group".
Чтобы отменить подписку на эту группу и больше не получать от нее сообщения, отправьте письмо на электронный адрес [hidden email].
Чтобы настроить другие параметры, перейдите по ссылке https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: ООDB на основе Pharo

Nikolay Kleptsov
конечно "подгрузка жемстоун способностей" выглядит возможно невероятно, но если спуститься с небес, имеем фаро, ког вм.

2 декабря 2014 г., 23:26 пользователь Denis Kudriashov <[hidden email]> написал:

2 декабря 2014 г., 19:34 пользователь Dennis Schetinin <[hidden email]> написал:
Я именно про GemStone, разумеется. Других настоящих ОБД я и не знаю, если честно.

Речь про то, чтобы сделать такой фреймворк, загрузка которого в Pharo превращала бы его в объектную базу данных со всеми фишками (ACID, пользователи) с максимально "прозрачностью" — чтобы написанное без БД приложение при загрузки этой библиотеки "автоматически" (без изменения кода) получало бы все эти вкусности… 

Что этому с технической т.з. мешает?

Здесь виртуалка должна быть специальная. Образ должен грузится в разделяемую виртуальную память и много чего из этого следует.
Такое наверно может быть возможно только в системах типа BeeSmalltalk или Mist. В них абсолютно все написано на смолотоке и изменяемо динамически, включая GC, JIT и так далее, и различные реализации этих компонент могли бы загружается в виде "пакетов". Но как и сами эти системы, "подгрузка жемстоун способностей" выглядит невероятно :)

--
--
http://groups.google.ru/group/sugr
---
Вы получили это сообщение, поскольку подписаны на группу "Russian Smalltalk User Group".
Чтобы отменить подписку на эту группу и больше не получать от нее сообщения, отправьте письмо на электронный адрес [hidden email].
Чтобы настроить другие параметры, перейдите по ссылке https://groups.google.com/d/optout.

--
--
http://groups.google.ru/group/sugr
---
Вы получили это сообщение, поскольку подписаны на группу "Russian Smalltalk User Group".
Чтобы отменить подписку на эту группу и больше не получать от нее сообщения, отправьте письмо на электронный адрес [hidden email].
Чтобы настроить другие параметры, перейдите по ссылке https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: ООDB на основе Pharo

Alex Kogan
In reply to this post by Denis Kudriashov
Ограниченость бесплатной версии Gemstone весьма относительная.
Бесплатная версия прекрасно используется в продакшн (в виде native
Seaside in Gemstone). Когда люди выходят за пределы ограничений
бесплатной версии, как правило  это уже реальный продукт, который
зарабатывает реальные деньги, люди сами готовы заплатить, чтобы иметь
реальную поддержку. Сделать что-то подобное конечно же можно, при
соотвественном вложении средств и людских ресурсов, но надо смотреть
на вещи реалистично. Не зря подозреваю Gemstone уже 30+ лет
оттачивают. Денис упоминал Магма http://wiki.squeak.org/squeak/2665
она конечно не без влияния Gemstone создавалось. Правда последнее что
я видел, работает вроде только с Pharo 1.4 может быть есть смысл
озачиться и подтянуть, а не изобретать новое, если так важен
opensource.

2014-12-02 9:26 GMT-08:00 Denis Kudriashov <[hidden email]>:

>
> 2 декабря 2014 г., 19:34 пользователь Dennis Schetinin <[hidden email]>
> написал:
>>
>> Я именно про GemStone, разумеется. Других настоящих ОБД я и не знаю, если
>> честно.
>>
>> Речь про то, чтобы сделать такой фреймворк, загрузка которого в Pharo
>> превращала бы его в объектную базу данных со всеми фишками (ACID,
>> пользователи) с максимально "прозрачностью" — чтобы написанное без БД
>> приложение при загрузки этой библиотеки "автоматически" (без изменения кода)
>> получало бы все эти вкусности…
>>
>> Что этому с технической т.з. мешает?
>
>
> Здесь виртуалка должна быть специальная. Образ должен грузится в разделяемую
> виртуальную память и много чего из этого следует.
> Такое наверно может быть возможно только в системах типа BeeSmalltalk или
> Mist. В них абсолютно все написано на смолотоке и изменяемо динамически,
> включая GC, JIT и так далее, и различные реализации этих компонент могли бы
> загружается в виде "пакетов". Но как и сами эти системы, "подгрузка жемстоун
> способностей" выглядит невероятно :)
>
> --
> --
> http://groups.google.ru/group/sugr
> ---
> Вы получили это сообщение, поскольку подписаны на группу "Russian Smalltalk
> User Group".
> Чтобы отменить подписку на эту группу и больше не получать от нее сообщения,
> отправьте письмо на электронный адрес [hidden email].
> Чтобы настроить другие параметры, перейдите по ссылке
> https://groups.google.com/d/optout.

--
--
http://groups.google.ru/group/sugr
---
Вы получили это сообщение, поскольку подписаны на группу Russian Smalltalk User Group.

Чтобы отменить подписку на эту группу и больше не получать от нее сообщения, отправьте письмо на электронный адрес [hidden email].
Настройки подписки и доставки писем: https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: ООDB на основе Pharo

Yuriy Mironenko
Может я скажу какой-нибудь...эээ...моветон.
Но GLORP же.

В смысле, я понимаю, что это не совсем то, что нужно. Но мне кажется, что то, что нужно, сравнительно легко может быть получено из глорпа. Над наследованием только подумать.

2 декабря 2014 г., 20:44 пользователь Alexander Kogan <[hidden email]> написал:
Ограниченость бесплатной версии Gemstone весьма относительная.
Бесплатная версия прекрасно используется в продакшн (в виде native
Seaside in Gemstone). Когда люди выходят за пределы ограничений
бесплатной версии, как правило  это уже реальный продукт, который
зарабатывает реальные деньги, люди сами готовы заплатить, чтобы иметь
реальную поддержку. Сделать что-то подобное конечно же можно, при
соотвественном вложении средств и людских ресурсов, но надо смотреть
на вещи реалистично. Не зря подозреваю Gemstone уже 30+ лет
оттачивают. Денис упоминал Магма http://wiki.squeak.org/squeak/2665
она конечно не без влияния Gemstone создавалось. Правда последнее что
я видел, работает вроде только с Pharo 1.4 может быть есть смысл
озачиться и подтянуть, а не изобретать новое, если так важен
opensource.

2014-12-02 9:26 GMT-08:00 Denis Kudriashov <[hidden email]>:
>
> 2 декабря 2014 г., 19:34 пользователь Dennis Schetinin <[hidden email]>
> написал:
>>
>> Я именно про GemStone, разумеется. Других настоящих ОБД я и не знаю, если
>> честно.
>>
>> Речь про то, чтобы сделать такой фреймворк, загрузка которого в Pharo
>> превращала бы его в объектную базу данных со всеми фишками (ACID,
>> пользователи) с максимально "прозрачностью" — чтобы написанное без БД
>> приложение при загрузки этой библиотеки "автоматически" (без изменения кода)
>> получало бы все эти вкусности…
>>
>> Что этому с технической т.з. мешает?
>
>
> Здесь виртуалка должна быть специальная. Образ должен грузится в разделяемую
> виртуальную память и много чего из этого следует.
> Такое наверно может быть возможно только в системах типа BeeSmalltalk или
> Mist. В них абсолютно все написано на смолотоке и изменяемо динамически,
> включая GC, JIT и так далее, и различные реализации этих компонент могли бы
> загружается в виде "пакетов". Но как и сами эти системы, "подгрузка жемстоун
> способностей" выглядит невероятно :)
>
> --
> --
> http://groups.google.ru/group/sugr
> ---
> Вы получили это сообщение, поскольку подписаны на группу "Russian Smalltalk
> User Group".
> Чтобы отменить подписку на эту группу и больше не получать от нее сообщения,
> отправьте письмо на электронный адрес [hidden email].
> Чтобы настроить другие параметры, перейдите по ссылке
> https://groups.google.com/d/optout.

--
--
http://groups.google.ru/group/sugr
---
Вы получили это сообщение, поскольку подписаны на группу Russian Smalltalk User Group.

Чтобы отменить подписку на эту группу и больше не получать от нее сообщения, отправьте письмо на электронный адрес [hidden email].
Настройки подписки и доставки писем: https://groups.google.com/d/optout.

--
--
http://groups.google.ru/group/sugr
---
Вы получили это сообщение, поскольку подписаны на группу "Russian Smalltalk User Group".
Чтобы отменить подписку на эту группу и больше не получать от нее сообщения, отправьте письмо на электронный адрес [hidden email].
Чтобы настроить другие параметры, перейдите по ссылке https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: ООDB на основе Pharo

Alex Kogan
Концепция подгрузить Gemstone, немного бессмысленна сама по себе в
силу того, что концепция и принцип работы конечного продукта в
известной степени меняется в условиях много-образности и унитарности
транзакций. Приходится решать вопрос как часто сохранять/обновлять
образ(ы). В случае с Gemstone можно это делать хоть после каждого
изменения обьекта, без каких-то принципиальных потерь, хотя несомненно
существует некий оптимальный обьем транзакции для записи.

2014-12-02 9:50 GMT-08:00 Юрий Мироненко <[hidden email]>:

> Может я скажу какой-нибудь...эээ...моветон.
> Но GLORP же.
>
> В смысле, я понимаю, что это не совсем то, что нужно. Но мне кажется, что
> то, что нужно, сравнительно легко может быть получено из глорпа. Над
> наследованием только подумать.
>
> 2 декабря 2014 г., 20:44 пользователь Alexander Kogan <[hidden email]>
> написал:
>>
>> Ограниченость бесплатной версии Gemstone весьма относительная.
>> Бесплатная версия прекрасно используется в продакшн (в виде native
>> Seaside in Gemstone). Когда люди выходят за пределы ограничений
>> бесплатной версии, как правило  это уже реальный продукт, который
>> зарабатывает реальные деньги, люди сами готовы заплатить, чтобы иметь
>> реальную поддержку. Сделать что-то подобное конечно же можно, при
>> соотвественном вложении средств и людских ресурсов, но надо смотреть
>> на вещи реалистично. Не зря подозреваю Gemstone уже 30+ лет
>> оттачивают. Денис упоминал Магма http://wiki.squeak.org/squeak/2665
>> она конечно не без влияния Gemstone создавалось. Правда последнее что
>> я видел, работает вроде только с Pharo 1.4 может быть есть смысл
>> озачиться и подтянуть, а не изобретать новое, если так важен
>> opensource.
>>
>> 2014-12-02 9:26 GMT-08:00 Denis Kudriashov <[hidden email]>:
>> >
>> > 2 декабря 2014 г., 19:34 пользователь Dennis Schetinin
>> > <[hidden email]>
>> > написал:
>> >>
>> >> Я именно про GemStone, разумеется. Других настоящих ОБД я и не знаю,
>> >> если
>> >> честно.
>> >>
>> >> Речь про то, чтобы сделать такой фреймворк, загрузка которого в Pharo
>> >> превращала бы его в объектную базу данных со всеми фишками (ACID,
>> >> пользователи) с максимально "прозрачностью" — чтобы написанное без БД
>> >> приложение при загрузки этой библиотеки "автоматически" (без изменения
>> >> кода)
>> >> получало бы все эти вкусности…
>> >>
>> >> Что этому с технической т.з. мешает?
>> >
>> >
>> > Здесь виртуалка должна быть специальная. Образ должен грузится в
>> > разделяемую
>> > виртуальную память и много чего из этого следует.
>> > Такое наверно может быть возможно только в системах типа BeeSmalltalk
>> > или
>> > Mist. В них абсолютно все написано на смолотоке и изменяемо динамически,
>> > включая GC, JIT и так далее, и различные реализации этих компонент могли
>> > бы
>> > загружается в виде "пакетов". Но как и сами эти системы, "подгрузка
>> > жемстоун
>> > способностей" выглядит невероятно :)
>> >
>> > --
>> > --
>> > http://groups.google.ru/group/sugr
>> > ---
>> > Вы получили это сообщение, поскольку подписаны на группу "Russian
>> > Smalltalk
>> > User Group".
>> > Чтобы отменить подписку на эту группу и больше не получать от нее
>> > сообщения,
>> > отправьте письмо на электронный адрес [hidden email].
>> > Чтобы настроить другие параметры, перейдите по ссылке
>> > https://groups.google.com/d/optout.
>>
>> --
>> --
>> http://groups.google.ru/group/sugr
>> ---
>> Вы получили это сообщение, поскольку подписаны на группу Russian Smalltalk
>> User Group.
>>
>> Чтобы отменить подписку на эту группу и больше не получать от нее
>> сообщения, отправьте письмо на электронный адрес
>> [hidden email].
>> Настройки подписки и доставки писем: https://groups.google.com/d/optout.
>
>
> --
> --
> http://groups.google.ru/group/sugr
> ---
> Вы получили это сообщение, поскольку подписаны на группу "Russian Smalltalk
> User Group".
> Чтобы отменить подписку на эту группу и больше не получать от нее сообщения,
> отправьте письмо на электронный адрес [hidden email].
> Чтобы настроить другие параметры, перейдите по ссылке
> https://groups.google.com/d/optout.

--
--
http://groups.google.ru/group/sugr
---
Вы получили это сообщение, поскольку подписаны на группу Russian Smalltalk User Group.

Чтобы отменить подписку на эту группу и больше не получать от нее сообщения, отправьте письмо на электронный адрес [hidden email].
Настройки подписки и доставки писем: https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: ООDB на основе Pharo

Denis Kudriashov

2 декабря 2014 г., 22:19 пользователь Alexander Kogan <[hidden email]> написал:
Концепция подгрузить Gemstone, немного бессмысленна сама по себе в
силу того, что концепция и принцип работы конечного продукта в
известной степени меняется в условиях много-образности и унитарности
транзакций. Приходится решать вопрос как часто сохранять/обновлять
образ(ы). В случае с Gemstone можно это делать хоть после каждого
изменения обьекта, без каких-то принципиальных потерь, хотя несомненно
существует некий оптимальный обьем транзакции для записи.

Не очень понял, что вы имеете в виду.
В традиционном смолтолке со статичной и отделенной виртуальной машиной не возможно уйти за рамки ее "аксиоматики". Например, если виртуалка не поддерживает нативные потоки, то, находясь внутри имиджа, реализовать их не получится.
 В BeeSmalltalk (Mist, Pinochio и другие аналоги) виртуальной машины как таковой не существует, есть только исполняемый и самомодифицируемый образ. И на одной из презентаций, его разработчики как раз демонстрировали подключение нативных нитей: они модифицировали управление памятью и работу планировщика. Все было сделано вживую, находясь внутри смолтолка, Точно также, по идее, может быть реализована виртуальная мультитранзакционная память. 



--
--
http://groups.google.ru/group/sugr
---
Вы получили это сообщение, поскольку подписаны на группу "Russian Smalltalk User Group".
Чтобы отменить подписку на эту группу и больше не получать от нее сообщения, отправьте письмо на электронный адрес [hidden email].
Чтобы настроить другие параметры, перейдите по ссылке https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: ООDB на основе Pharo

Alex Kogan
нативные нити и планировщик на мой взгляд не совсем то о чем я говорю.
Я имею ввиду прикладное значение много образности. Скажем имеем некий
image(образ) root(0), который представляет собой дерево из обьектов
ABC где B cодержит пустую коллекцию, а в С имеет место под некую
переменную. Стартуем две виртуальные машины, в GEMSTONE виртуальные
машины называются Gems, которые читают исходный образ (дерево
обьектов). За чтение образа, его версии, синхронизацию отвечает
посредник, так называемый Stone. Таким образом имеем схему
Gem (Session 1) -------------->Stone<--------------Gem(Session 2).
Каждaя виртуальная машина, видит один и только один образ, читает,
модифицирует обьекты в нем. Понятия по большому с чету о других Gems.
Вот так можно представить жизненный цикл этих двух образов.

Session 1 ....commit ..(верс 1)...........................abort
(хватаем последнюю версию (2)
A->B->{}       A->B->{D. D . D}                            A->B->{D. D . D}
|                   |                                                   |
C(0)              C(0)                                              C($10000)

Stone
версия(0)..->..версия(1)..синхр . ->   версия (2) выбр верс
(0).............выбрасываем верс(1)

Session 2..................commit....................(версия 2).....
A->B->{}                    A->B->{}                    A->B->{D. D . D}
|                                |                               |
C($0)                          C($10000)                 C($10000)

Изначально обе сессии видят нулевую версию образа. Сессия №1 добавляет
несколько обьектов в коллекцию и дает комманду commit на сохранение
изменений. Stone получает список изменений. И создает новую мастер
версию обьектного дерева (root 1). Одна из задач для Stone - это
помнить, что Сессия №2 все еще работает с исходной версией №0, поэтому
ему теперь приходится помнить обе версии, на случай если Сессия №2
захочет подгрузить обьект B, то она получит пустую коллекцию,
соответсвующую версии (0) ассоциируемой с данной виртуальной машиной.
Весь образ в память виртуалки не грузится, а только некие его части. В
реальной базе С и B могут быть сильно удалены, а образ очень большой.
Тем временем Сессия №2 одновременно, или последовательно (не суть
важно по времени) обновляет обьект С и издает комманду commit. Stone
обьединяет версию (1) и изменения исходящие от Сессии 2 и создает
версию №2 обьектного дерева. Эта версия становится исходным образом
для Сессии №2. Одновременно выбрасывается в мусор версия №0, поскольку
ни одна из сессий на больше  в ней не нуждается. Сессия №1 продолжает
наблюдать версию №1 (т.е читая обьект С, получает $0) до тех пор, пока
не издается команда abort, на обновление образа, после чего Stone
вручает ей версию №2. Теперь обе сессии видят синхронизированный,
одинаковый образ. Stone отправляет версию №1 в мусор.

Таким образом 2 сессии могут иметь 1 или 2 образа одновременно, 3 - 3
и т.д. Сессий может быть и сто, и тысяча и десять. Все становиться
очень живым и интересным. Естественно могут быть конфликты если две
сессии модифицировали один и тот же обьект.  Тогда кто не успел тот
опоздал, первый commit выигрывает (optimistic locking).

2014-12-02 12:40 GMT-08:00 Denis Kudriashov <[hidden email]>:

>
> 2 декабря 2014 г., 22:19 пользователь Alexander Kogan <[hidden email]>
> написал:
>>
>> Концепция подгрузить Gemstone, немного бессмысленна сама по себе в
>> силу того, что концепция и принцип работы конечного продукта в
>> известной степени меняется в условиях много-образности и унитарности
>> транзакций. Приходится решать вопрос как часто сохранять/обновлять
>> образ(ы). В случае с Gemstone можно это делать хоть после каждого
>> изменения обьекта, без каких-то принципиальных потерь, хотя несомненно
>> существует некий оптимальный обьем транзакции для записи.
>
>
> Не очень понял, что вы имеете в виду.
> В традиционном смолтолке со статичной и отделенной виртуальной машиной не
> возможно уйти за рамки ее "аксиоматики". Например, если виртуалка не
> поддерживает нативные потоки, то, находясь внутри имиджа, реализовать их не
> получится.
>  В BeeSmalltalk (Mist, Pinochio и другие аналоги) виртуальной машины как
> таковой не существует, есть только исполняемый и самомодифицируемый образ. И
> на одной из презентаций, его разработчики как раз демонстрировали
> подключение нативных нитей: они модифицировали управление памятью и работу
> планировщика. Все было сделано вживую, находясь внутри смолтолка, Точно
> также, по идее, может быть реализована виртуальная мультитранзакционная
> память.
>
>
>
> --
> --
> http://groups.google.ru/group/sugr
> ---
> Вы получили это сообщение, поскольку подписаны на группу "Russian Smalltalk
> User Group".
> Чтобы отменить подписку на эту группу и больше не получать от нее сообщения,
> отправьте письмо на электронный адрес [hidden email].
> Чтобы настроить другие параметры, перейдите по ссылке
> https://groups.google.com/d/optout.

--
--
http://groups.google.ru/group/sugr
---
Вы получили это сообщение, поскольку подписаны на группу Russian Smalltalk User Group.

Чтобы отменить подписку на эту группу и больше не получать от нее сообщения, отправьте письмо на электронный адрес [hidden email].
Настройки подписки и доставки писем: https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: ООDB на основе Pharo

Alex Kogan
Stone, Gem №1 и Gem № 2 могут находиться на одной и той же машине, а
могут на разных концах планеты

2014-12-02 15:18 GMT-08:00 Alexander Kogan <[hidden email]>:

> нативные нити и планировщик на мой взгляд не совсем то о чем я говорю.
> Я имею ввиду прикладное значение много образности. Скажем имеем некий
> image(образ) root(0), который представляет собой дерево из обьектов
> ABC где B cодержит пустую коллекцию, а в С имеет место под некую
> переменную. Стартуем две виртуальные машины, в GEMSTONE виртуальные
> машины называются Gems, которые читают исходный образ (дерево
> обьектов). За чтение образа, его версии, синхронизацию отвечает
> посредник, так называемый Stone. Таким образом имеем схему
> Gem (Session 1) -------------->Stone<--------------Gem(Session 2).
> Каждaя виртуальная машина, видит один и только один образ, читает,
> модифицирует обьекты в нем. Понятия по большому с чету о других Gems.
> Вот так можно представить жизненный цикл этих двух образов.
>
> Session 1 ....commit ..(верс 1)...........................abort
> (хватаем последнюю версию (2)
> A->B->{}       A->B->{D. D . D}                            A->B->{D. D . D}
> |                   |                                                   |
> C(0)              C(0)                                              C($10000)
>
> Stone
> версия(0)..->..версия(1)..синхр . ->   версия (2) выбр верс
> (0).............выбрасываем верс(1)
>
> Session 2..................commit....................(версия 2).....
> A->B->{}                    A->B->{}                    A->B->{D. D . D}
> |                                |                               |
> C($0)                          C($10000)                 C($10000)
>
> Изначально обе сессии видят нулевую версию образа. Сессия №1 добавляет
> несколько обьектов в коллекцию и дает комманду commit на сохранение
> изменений. Stone получает список изменений. И создает новую мастер
> версию обьектного дерева (root 1). Одна из задач для Stone - это
> помнить, что Сессия №2 все еще работает с исходной версией №0, поэтому
> ему теперь приходится помнить обе версии, на случай если Сессия №2
> захочет подгрузить обьект B, то она получит пустую коллекцию,
> соответсвующую версии (0) ассоциируемой с данной виртуальной машиной.
> Весь образ в память виртуалки не грузится, а только некие его части. В
> реальной базе С и B могут быть сильно удалены, а образ очень большой.
> Тем временем Сессия №2 одновременно, или последовательно (не суть
> важно по времени) обновляет обьект С и издает комманду commit. Stone
> обьединяет версию (1) и изменения исходящие от Сессии 2 и создает
> версию №2 обьектного дерева. Эта версия становится исходным образом
> для Сессии №2. Одновременно выбрасывается в мусор версия №0, поскольку
> ни одна из сессий на больше  в ней не нуждается. Сессия №1 продолжает
> наблюдать версию №1 (т.е читая обьект С, получает $0) до тех пор, пока
> не издается команда abort, на обновление образа, после чего Stone
> вручает ей версию №2. Теперь обе сессии видят синхронизированный,
> одинаковый образ. Stone отправляет версию №1 в мусор.
>
> Таким образом 2 сессии могут иметь 1 или 2 образа одновременно, 3 - 3
> и т.д. Сессий может быть и сто, и тысяча и десять. Все становиться
> очень живым и интересным. Естественно могут быть конфликты если две
> сессии модифицировали один и тот же обьект.  Тогда кто не успел тот
> опоздал, первый commit выигрывает (optimistic locking).
>
> 2014-12-02 12:40 GMT-08:00 Denis Kudriashov <[hidden email]>:
>>
>> 2 декабря 2014 г., 22:19 пользователь Alexander Kogan <[hidden email]>
>> написал:
>>>
>>> Концепция подгрузить Gemstone, немного бессмысленна сама по себе в
>>> силу того, что концепция и принцип работы конечного продукта в
>>> известной степени меняется в условиях много-образности и унитарности
>>> транзакций. Приходится решать вопрос как часто сохранять/обновлять
>>> образ(ы). В случае с Gemstone можно это делать хоть после каждого
>>> изменения обьекта, без каких-то принципиальных потерь, хотя несомненно
>>> существует некий оптимальный обьем транзакции для записи.
>>
>>
>> Не очень понял, что вы имеете в виду.
>> В традиционном смолтолке со статичной и отделенной виртуальной машиной не
>> возможно уйти за рамки ее "аксиоматики". Например, если виртуалка не
>> поддерживает нативные потоки, то, находясь внутри имиджа, реализовать их не
>> получится.
>>  В BeeSmalltalk (Mist, Pinochio и другие аналоги) виртуальной машины как
>> таковой не существует, есть только исполняемый и самомодифицируемый образ. И
>> на одной из презентаций, его разработчики как раз демонстрировали
>> подключение нативных нитей: они модифицировали управление памятью и работу
>> планировщика. Все было сделано вживую, находясь внутри смолтолка, Точно
>> также, по идее, может быть реализована виртуальная мультитранзакционная
>> память.
>>
>>
>>
>> --
>> --
>> http://groups.google.ru/group/sugr
>> ---
>> Вы получили это сообщение, поскольку подписаны на группу "Russian Smalltalk
>> User Group".
>> Чтобы отменить подписку на эту группу и больше не получать от нее сообщения,
>> отправьте письмо на электронный адрес [hidden email].
>> Чтобы настроить другие параметры, перейдите по ссылке
>> https://groups.google.com/d/optout.

--
--
http://groups.google.ru/group/sugr
---
Вы получили это сообщение, поскольку подписаны на группу Russian Smalltalk User Group.

Чтобы отменить подписку на эту группу и больше не получать от нее сообщения, отправьте письмо на электронный адрес [hidden email].
Настройки подписки и доставки писем: https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: ООDB на основе Pharo

Dennis Schetinin
Александр, спасибо!

А что нужно сделать/переделать в Pharo чтобы что-то подобное можно было реализовать?


--

Best regards,


Dennis Schetinin


3 декабря 2014 г., 3:28 пользователь Alexander Kogan <[hidden email]> написал:
Stone, Gem №1 и Gem № 2 могут находиться на одной и той же машине, а
могут на разных концах планеты

2014-12-02 15:18 GMT-08:00 Alexander Kogan <[hidden email]>:
> нативные нити и планировщик на мой взгляд не совсем то о чем я говорю.
> Я имею ввиду прикладное значение много образности. Скажем имеем некий
> image(образ) root(0), который представляет собой дерево из обьектов
> ABC где B cодержит пустую коллекцию, а в С имеет место под некую
> переменную. Стартуем две виртуальные машины, в GEMSTONE виртуальные
> машины называются Gems, которые читают исходный образ (дерево
> обьектов). За чтение образа, его версии, синхронизацию отвечает
> посредник, так называемый Stone. Таким образом имеем схему
> Gem (Session 1) -------------->Stone<--------------Gem(Session 2).
> Каждaя виртуальная машина, видит один и только один образ, читает,
> модифицирует обьекты в нем. Понятия по большому с чету о других Gems.
> Вот так можно представить жизненный цикл этих двух образов.
>
> Session 1 ....commit ..(верс 1)...........................abort
> (хватаем последнюю версию (2)
> A->B->{}       A->B->{D. D . D}                            A->B->{D. D . D}
> |                   |                                                   |
> C(0)              C(0)                                              C($10000)
>
> Stone
> версия(0)..->..версия(1)..синхр . ->   версия (2) выбр верс
> (0).............выбрасываем верс(1)
>
> Session 2..................commit....................(версия 2).....
> A->B->{}                    A->B->{}                    A->B->{D. D . D}
> |                                |                               |
> C($0)                          C($10000)                 C($10000)
>
> Изначально обе сессии видят нулевую версию образа. Сессия №1 добавляет
> несколько обьектов в коллекцию и дает комманду commit на сохранение
> изменений. Stone получает список изменений. И создает новую мастер
> версию обьектного дерева (root 1). Одна из задач для Stone - это
> помнить, что Сессия №2 все еще работает с исходной версией №0, поэтому
> ему теперь приходится помнить обе версии, на случай если Сессия №2
> захочет подгрузить обьект B, то она получит пустую коллекцию,
> соответсвующую версии (0) ассоциируемой с данной виртуальной машиной.
> Весь образ в память виртуалки не грузится, а только некие его части. В
> реальной базе С и B могут быть сильно удалены, а образ очень большой.
> Тем временем Сессия №2 одновременно, или последовательно (не суть
> важно по времени) обновляет обьект С и издает комманду commit. Stone
> обьединяет версию (1) и изменения исходящие от Сессии 2 и создает
> версию №2 обьектного дерева. Эта версия становится исходным образом
> для Сессии №2. Одновременно выбрасывается в мусор версия №0, поскольку
> ни одна из сессий на больше  в ней не нуждается. Сессия №1 продолжает
> наблюдать версию №1 (т.е читая обьект С, получает $0) до тех пор, пока
> не издается команда abort, на обновление образа, после чего Stone
> вручает ей версию №2. Теперь обе сессии видят синхронизированный,
> одинаковый образ. Stone отправляет версию №1 в мусор.
>
> Таким образом 2 сессии могут иметь 1 или 2 образа одновременно, 3 - 3
> и т.д. Сессий может быть и сто, и тысяча и десять. Все становиться
> очень живым и интересным. Естественно могут быть конфликты если две
> сессии модифицировали один и тот же обьект.  Тогда кто не успел тот
> опоздал, первый commit выигрывает (optimistic locking).
>
> 2014-12-02 12:40 GMT-08:00 Denis Kudriashov <[hidden email]>:
>>
>> 2 декабря 2014 г., 22:19 пользователь Alexander Kogan <[hidden email]>
>> написал:
>>>
>>> Концепция подгрузить Gemstone, немного бессмысленна сама по себе в
>>> силу того, что концепция и принцип работы конечного продукта в
>>> известной степени меняется в условиях много-образности и унитарности
>>> транзакций. Приходится решать вопрос как часто сохранять/обновлять
>>> образ(ы). В случае с Gemstone можно это делать хоть после каждого
>>> изменения обьекта, без каких-то принципиальных потерь, хотя несомненно
>>> существует некий оптимальный обьем транзакции для записи.
>>
>>
>> Не очень понял, что вы имеете в виду.
>> В традиционном смолтолке со статичной и отделенной виртуальной машиной не
>> возможно уйти за рамки ее "аксиоматики". Например, если виртуалка не
>> поддерживает нативные потоки, то, находясь внутри имиджа, реализовать их не
>> получится.
>>  В BeeSmalltalk (Mist, Pinochio и другие аналоги) виртуальной машины как
>> таковой не существует, есть только исполняемый и самомодифицируемый образ. И
>> на одной из презентаций, его разработчики как раз демонстрировали
>> подключение нативных нитей: они модифицировали управление памятью и работу
>> планировщика. Все было сделано вживую, находясь внутри смолтолка, Точно
>> также, по идее, может быть реализована виртуальная мультитранзакционная
>> память.
>>
>>
>>
>> --
>> --
>> http://groups.google.ru/group/sugr
>> ---
>> Вы получили это сообщение, поскольку подписаны на группу "Russian Smalltalk
>> User Group".
>> Чтобы отменить подписку на эту группу и больше не получать от нее сообщения,
>> отправьте письмо на электронный адрес [hidden email].
>> Чтобы настроить другие параметры, перейдите по ссылке
>> https://groups.google.com/d/optout.

--
--
http://groups.google.ru/group/sugr
---
Вы получили это сообщение, поскольку подписаны на группу Russian Smalltalk User Group.

Чтобы отменить подписку на эту группу и больше не получать от нее сообщения, отправьте письмо на электронный адрес [hidden email].
Настройки подписки и доставки писем: https://groups.google.com/d/optout.

--
--
http://groups.google.ru/group/sugr
---
Вы получили это сообщение, поскольку подписаны на группу "Russian Smalltalk User Group".
Чтобы отменить подписку на эту группу и больше не получать от нее сообщения, отправьте письмо на электронный адрес [hidden email].
Чтобы настроить другие параметры, перейдите по ссылке https://groups.google.com/d/optout.
123