funikovyuri М.ГоловановЧитается только то, что уже есть в таблицах.

Это, если говорить мягко, неправда...


То есть как неправда? В ISAM доступ к конкретной записи всегда последователен - что на чтение, что на обновление. Что можно прочитать в каждый данный момент, кроме того, что в этот момент есть в записи?

funikovyuriХм... Иногда лучше жевать....

Вот именно. SQL транзакции позволяют беззаботно жевать. Был у меня знакомый программист... всегда писал так:


и спокойно жевал. Все железно и по правилам. А не тянет - берем сервак покруче...

funikovyuri То есть как неправда? В ISAM доступ к конкретной записи всегда последователен - что на чтение, что на обновление. Что можно прочитать в каждый данный момент, кроме того, что в этот момент есть в записи?

Вы б почитали про уровни изоляции чтоли...


А как уровни изоляции применимы к ISAM базе данных? Вы бы про ISAM почитали, что ли...

ррмяф М.Голованов
То есть как неправда? В ISAM доступ к конкретной записи всегда последователен - что на чтение, что на обновление. Что можно прочитать в каждый данный момент, кроме того, что в этот момент есть в записи?

Я бы вам посоветовал вначале прочитать теорию БД.
Что такое "грязное чтение" (вы, как я понимаю, работаете именно так) и к чему оно приводит.

Вам тоже посоветую почитать оную теорию. Узнать, что такое ISAM... Или Вы только по SQL?

funikovyuriНе совсем понял зачем в приведенном примере begin tran/commit, но так или иначе искренне советую перестать пороть чушь

Я вот тоже не совсем понял, зачем он так писал. И искренне выгнал его.

1024насколько я понял вы с хибернейтом не очень. Не засоряйте топик. Либо поделитесь решением вопросов производительности

... сначала почитав соответствующий раздел в документации:

19. Improving performance

Кроме того, по ссылке

http://www.hibernate.org/?cmd=srchdoc&q=performance

можно найти приличный набор заметок по этому вопросу. Правда, там все с основном о тюнинге. Принципиальный же ответ дан выше: не устраивает Hibernate - переходите на непосредственный JDBC и хранимые процедуры. За счет времени, потраченного на соответствующее кодирование.

cooluserМои 5 копеек

2. Проект с использованием Hibernate должен работать не медленее, чем аналогичный, но без использования Hibernate, поскольку:
2.1 У Hibernate есть свой собственный кэш, которым можно и нужно пользоваться
2.2 Hibernate не запрещает использовать обычные SQL запросы и специфические возможность СУБД там, где это действительно нужно

Второе утверждение верно без оговорок.

Первое утверждение верно только при определенных условиях:

а) в течение некоторого времени работы приложения доступ к записи осуществляется многократно,

б) запись в течение этого времени может обновляться.

В этом и только в этом случае имеет смысл держать запись в памяти (кэш - это по сути копия части содержимого БД) с выигрышем в производительности. Записи, читаемые эпизодически, держать в памяти смысла нет - мало того, что есть более быстрые способы один раз массово прочитать такие записи, так они еще будут выталкивать из кэша записи, которые там действительно имеет смысл держать (память-то не безразмерна).

То же самое в точности верно для EJB 1..2 контейнеров. Поэтому когда мы писали приложения под такие контейнеры (типа WebLogic и Orion), мы всегда использовали два класса объектов, с которыми работали session beans: а) entity beans - кэшируемые записи - для текущей обработки и б) query engine (класс, поставляющий записи через JDBC и хранимые процедуры) - для исторических данных. Все летало.

Hibernate позволяет в принципе до JDBC не опускаться и обойтись HQL - однако с некоторыми накладными расходами. Поэтому для исторических данных я всегда пользуюсь JDBC - как я и писал выше.

Короче, если руководствоваться здравым смыслом и не заставлять Hibernate работать с записями, с которыми она работать не должна, проблем с производительностью она не доставит. Однако здравый смысл - вещь редкая...