BTW we are working to improve this API further in 4.1 (to expose isolation
levels, etc), so if you have any ideas how to make it more powerful and easy to
use, suggestions are welcome.
Andrus
> On Mar 20, 2018, at 7:20 PM, John Huss <johnth...@gmail.com> wrote:
>
> To rollback you have to use the more explicit API:
>
> TransactionFactory txFactory =
> CayenneRuntime.getThreadInjector().getInstance(TransactionFactory.class);
> Transaction tx = txFactory.createTransaction();
> tx.begin();
> try {
> // do stuff
>
> context.commitChanges();
> tx.commit();
> } catch (Exception e) {
> tx.rollback();
> throw e;
> }
>
>
>
>
> On Tue, Mar 20, 2018 at 11:07 AM Maik Musall <m...@selbstdenker.ag> wrote:
>
>> First an additional answer: you can return whatever you want. That will
>> then become the return value of the performInTransaction() call.
>>
>> But I have a related question. How is an explicit rollback supposed to
>> work there? If I halfway through decide to roll back the entire
>> transaction, after a few commitChanges() already have happened, how do I do
>> that?
>>
>> I tried
>>
>> context.rollbackChangesLocally();
>> BaseTransaction.getThreadTransaction().rollback();
>>
>> but then I get
>>
>> java.lang.IllegalStateException: Transaction must have ‘STATUS_ACTIVE’ to
>> be committed. Current status: STATUS_ROLLEDBACK
>>
>> What seems to work is throwing a CayenneRuntimeException, but that will
>> get rethrown after the rollback, so I would have to catch that again
>> outside the performInTransaction() call, which doesn't feel how it's
>> supposed to work.
>>
>> Maik
>>
>>
>>
>>> Am 20.03.2018 um 16:40 schrieb John Huss <johnth...@gmail.com>:
>>>
>>> performInTransaction just encapsulates a database transaction, so it has
>> no
>>> affect on the object (ORM) level, it only affects what is visible in the
>>> database. So the behavior with commitChanges() is the same as it would
>> be
>>> outside a performInTransaction block.
>>>
>>>
>>> On Tue, Mar 20, 2018 at 10:25 AM Juan Manuel Diaz Lara
>>> <jmdia...@yahoo.com.invalid> wrote:
>>>
>>>> runtime.performInTransaction(() -> {
>>>> // ... do some changes
>>>> context.commitChanges();
>>>>
>>>> // ... do more changes
>>>> context.commitChanges();
>>>>
>>>> return true;
>>>> }); Previous code is an example on "Guide to 4.0 Features".
>>>> My questions are:
>>>> - What is then persistence state of objects after first
>> commitChanges()
>>>> ?
>>>>
>>>> - If second commitChanges() fails, what happen to the persistence
>>>> state coming from firs commitChages() ?
>>>> - What happen if we return false?
>>>> Atte. Juan Manuel Díaz Lara
>>
>>
