Зачем такую херню делать

Транзакция должна быть коротенькой

а как транзакцию можно передавать?

Транзакция должна быть коротенькой

я с этим не спорю, но сам подход цеплять ее к потоку где то в недрах кода мне не нравится

я хочу чтобы она была на виду

а как транзакцию можно передавать?

может он имеет в виду присоединиться к транзакции?

может он имеет в виду присоединиться к транзакции?

использовать транзакцию в разных потоках и в разных запросах в пределах одного метода например

Вообще передавать по сути пожешь и конекшин

Просто коммит не делать

это верно, я так и делаю сейчас но в Java это все выглядит стремно

после Scala

использовать транзакцию в разных потоках и в разных запросах в пределах одного метода например

а кейс какой?

а кейс какой?

Херовый))))

а кейс какой?

parallelStream()

и там сохраняем че нить

понятно, пиздец

Наркоман

ясное дело для JPA это пиздец

понятно, пиздец

Надо его отпиздить

нафига ты параллельно что-то сохраняешь, дружок?

ясное дело для JPA это пиздец

Это всегда пиздец

использовать транзакцию в разных потоках и в разных запросах в пределах одного метода например

типа для конкретного метода открыть одну транзакцию и никогда не закрывать?

типа для конкретного метода открыть одну транзакцию и никогда не закрывать?

похоже на это

@Transactional(propagation = Propagation.REQUIRED)

мне не хочется чтобы транзакция цеплялась к потоку вот и все

Видимо у него бесконечный пул)

не подойдет?

Видимо у него бесконечный пул)

parallelStream это не бесконечный пул

Я про пул конекшинов

транзакция открывается на уровня одного соединения

лол

о чем ты?

В общем ты делаешь какую-то дичь

транзакция открывается на уровня одного соединения

Я это знаю

Я про то что ты скорее всего пул конектов выберешь или все потоки в параллельных стримах заблочишь

бизнес задача какая

мотивация какая

бизнес задача какая

Сделать хуево видимо

http://stackoverflow.com/questions/18897092/sharing-a-jdbc-connection-across-threads

I wouldn't recommend you to share connection between threads, as operations with connection is quite slow and overall performance of you application may harm.

поверим этому индусу

индус точно не может врать!

Ай промис ит мистер

хотя

он в епаме работает

¯\_(ツ)_/¯

короче задача простая и с кучей потоков не связанная, хочется объявить транзакцию и выполнить работу в ее рамках, но нельзя тащить @Transactional и т.д. в том числе не хочется писать свой TransactionHolder который будет кешировать все в рамках потока, на Scala это делается изи в пол пинка, делаешь implicit параметр к методу и все збс, в java же учитывая что все клепают DAO(в том числе и я) это превращается в пиздец, потому что не хочется в метод добавлять Connection последним параметров, а если делать его на уровне конструктора, то объект должен жить столько же времени сколько и соединения(т.е. относительно не долго)

http://stackoverflow.com/questions/6952294/how-to-share-one-transaction-between-multi-threads

короче задача простая и с кучей потоков не связанная, хочется объявить транзакцию и выполнить работу в ее рамках, но нельзя тащить @Transactional и т.д. в том числе не хочется писать свой TransactionHolder который будет кешировать все в рамках потока, на Scala это делается изи в пол пинка, делаешь implicit параметр к методу и все збс, в java же учитывая что все клепают DAO(в том числе и я) это превращается в пиздец, потому что не хочется в метод добавлять Connection последним параметров, а если делать его на уровне конструктора, то объект должен жить столько же времени сколько и соединения(т.е. относительно не долго)

Мда)

здесь JTA советуют

Мда)

я правильно понял, что Иван хочет свой Transactional запилить?

короче задача простая и с кучей потоков не связанная, хочется объявить транзакцию и выполнить работу в ее рамках, но нельзя тащить @Transactional и т.д. в том числе не хочется писать свой TransactionHolder который будет кешировать все в рамках потока, на Scala это делается изи в пол пинка, делаешь implicit параметр к методу и все збс, в java же учитывая что все клепают DAO(в том числе и я) это превращается в пиздец, потому что не хочется в метод добавлять Connection последним параметров, а если делать его на уровне конструктора, то объект должен жить столько же времени сколько и соединения(т.е. относительно не долго)

Прост у конекшина сет коммит фолс делаешь

Прост у конекшина сет коммит фолс делаешь

блин чувак отстань от меня с этой херней я в курсе всего этого

блин чувак отстань от меня с этой херней я в курсе всего этого

Да вот видимо нет)

ты мой коммент читал, понял что там написано?

ты мой коммент читал, понял что там написано?

джава гавно, скала имлиситы рулят?

не вегда но в этом случае да

java не гавно

ты мой коммент читал, понял что там написано?

Тебе уже 300 раз написали, что ты несёшь дичь

написал ты и Дима, два главных местных троля

Другие просто до сих пор феиспалмят с тебя

написал ты и Дима, два главных местных троля

мне кажется или это неуважение к Руслану?

вот о чем я говорю http://scalikejdbc.org/documentation/transaction.html

ERROR: S client not available

примерно

в java такое не сделаешь

Скалаик в пример

Да что с тобой

в java такое не сделаешь

ты по ссылке имел в виду #localTx block?

DB localTx { implicit session =>

объявляется сессия и нигде внутри блока явно не передается

хотя фактически она там юзается везде и код не грязный

какой кошмар)

ну конечно @Transactional на методе лучше, хотя никто не в курсе че там под капотом и пишут например @Async @Transactional

ну конечно @Transactional на методе лучше, хотя никто не в курсе че там под капотом и пишут например @Async @Transactional

А асинк транзакшинал будет работать

ты уверен?

Угу

а если транзакция уже была открыта

Шта

Шта

ты че не открываешь уже открытую транзакцию пока она открывается?

у тебя в методе с @Transactional вызывается другой метод с @Async @Transactional что произойдет в таком случае

будет использоваться старая транзакция или откроется новая?

Вообще спринг создаёт прост прокси

будет использоваться старая транзакция или откроется новая?

а какой пропогейщн по умолчанию

у тебя в методе с @Transactional вызывается другой метод с @Async @Transactional что произойдет в таком случае

падает интеграционный тест, приходит тимлид и пиздит за такой код по лицу

я не помню

падает интеграционный тест, приходит тимлид и пиздит за такой код по лицу

вай это же спринг все его юзают работает в 100% случаев

и JPA тоже

у тебя в методе с @Transactional вызывается другой метод с @Async @Transactional что произойдет в таком случае

Если ты так делаешь то ссзб

а какой пропогейщн по умолчанию

по умолчанию должен поддерживать старую

но новую открывает только если реквайрс нью, и вряд ли он по умолчанию стоит

тогда смотри у тебя транзакция крепится к потоку, ты вызываешь метод в другом потоке если он пытается использовать старую транзакцию то после того как закроется первый поток эта транзакция становится невалидной

секешь о чем я?

чот сложно, транзакции шарить между потоками

не сталкивался

я не шарю их между потоками, просто какой то неопытный чел сделал метод @Async @Transactional