Версия для печати темы
Нажмите сюда для просмотра этой темы в оригинальном формате
Форум программистов > Java EE (J2EE) и Spring > Продолжительность транзакции


Автор: Embedded 26.4.2011, 09:35
Здравствуйте
Просматривая чужой код обнаружил что некоторые программисты между вызовами методов транзакции (JPA) begin() и commit() помещают достаточно большие куски кода, иногда метод с кучей проверок и некоторыми действиями на прямую не связанными с сохранением объекта в БД или загрузой из БД.
Подскажите пожалуйста, а вообще большое значение имеет время прошедшее с начала ( begin() ) транзакции и до ее конца ( commit() )? Мне кажется, что чем короче транзакция по времени тем лучше... 

Автор: LSD 26.4.2011, 09:52
Цитата(Embedded @  26.4.2011,  10:35 Найти цитируемый пост)
Мне кажется, что чем короче транзакция по времени тем лучше...  

С точки зрения СУБД - да. А с точки зрения программиста, лучше автоматически начинать транзакцию при вызове метода и завершать по его окончании.

Кстати Oracle достаточно спокойно относится к длинным транзакциям.

Автор: Embedded 26.4.2011, 10:03
Спасибо за помощь LSD! К сожалению я месяц назад начал изучать Java и почти тогда же БД. Использую PostgreSQL, но многих нюансов не знаю. Как наберу сотню плюс за мной, не забуду)
Еще раз спасибо!

Автор: LSD 26.4.2011, 10:54
Тут, как и во всем другом, нужен разумный компромисс. Между удобством написания и ограничениями используемых инструментов.

Пока время работы твоих методов измеряется секундами, можно особо не переживать. Когда оно перейдет на минуты/десятки минут, тут уже стоит думать над оптимизацией.

Автор: Embedded 26.4.2011, 11:26
LSD, 
Там у меня пока примитивные проверки... Например заполнил ли пользователь поле или нет и т.д. Просто использя механизм исключений все проверки получается выполнить достаточно аккуратно. Но это получается не запутанно сделать только если работу с транзакциями спрятать в абстрактный класс типа такого:
Код

public abstract class TransactionalClass  extends AbstractClass {

    protected abstract void doTransactionWork();
    
    @Override
    protected void doMainWork() {
        HelperTransactionUnit unit = new HelperTransactionUnit() {
            protected void doTransaction() {
                doTransactionalWork();
            }
        };
        unit.execute();
    }

}

Названия дал условные. Вся работа с транзакциями проводится в классе HelperTransactionUnit (в методе execute(), который в свою очередь вызывает  doTransaction() между begin() и commit()), раньше я производил эту работу в TransactionalClass, но мне посоветовали еще добавить класс HelperTransactionUnit дабы уменьшить зависимости, хотя честно сказать у меня проект маленький чтобы возникли подобные проблемы с зависимостями...
Вот такая история.. К сожалению поскольку знаний у меня мало очень, а про разнообразные методы программирования я уже немного почитал, я начинаю думать как облегчить себе жизнь благодаря новым знаниями и не всегда выходит хорошо или даже чаще выходит плохо

Автор: LSD 26.4.2011, 12:19
Можно например использовать декларативные транзакции. В том же спринге это делается http://static.springsource.org/spring/docs/2.0.x/reference/transaction.html.
Аннотируешь класс или метод как @Transactional и спринг будет автоматически начинать транзакцию при вызове метода и завершать ее при выходе из метода. Если было исключение, то транзакция будет отменена.
Код

@Transactional
public class DefaultFooService implements FooService {

    Foo getFoo(String fooName);

    Foo getFoo(String fooName, String barName);

    void insertFoo(Foo foo);

    void updateFoo(Foo foo);
}

Автор: Embedded 26.4.2011, 12:29
LSD, 
Я начал с урока Stampede и поскольку кода написал много, а до спринга еще не добрался, то подобные радости мне пока еще недоступны. И часто приходится в одной транзакции произвести операции чтения/записи с различными сущностями так, что пока удобно делать как описал выше.
Спасибо за советы и помощь LSD! Не обессудьте уж, что задаю примитивные вопросы, мне еще учиться и учиться...

Powered by Invision Power Board (http://www.invisionboard.com)
© Invision Power Services (http://www.invisionpower.com)