At some point we turned it on because there was a procedure that caused
issues since it handled its own transactions but I believe we can work
around that. I Turned it back off and it looks like transactions are now
working correctly. Out of curiosity since there's still the
possibility that I might need them to be on for this specific procedure,
can I toggle that setting on and off? I see that I can access the
ServerModule from my serverRuntime but I'm not sure how I can edit it since
the configure method requires a binder and I don't know how to get that.
On Mon, Nov 11, 2024 at 3:55 PM John Huss <johnth...@gmail.com> wrote:
> On Mon, Nov 11, 2024 at 2:58 PM Christian Gonzalez <
> christian.gonza...@smartscrubs.com> wrote:
>
> > Hi John, I tried making the transaction using the transaction factory and
> > the changes that the objectContext committed were still reflected in the
> > database. I added a print statement before the transaction is supposed to
> > be rolled back and noticed that when it does the cayenne logs show these
> > messages.
> >
> > INFO o.apache.cayenne.log.JdbcEventLogger - *** no rollback -
> transaction
> > controlled externally.
> > INFO o.apache.cayenne.log.JdbcEventLogger - *** no rollback -
> transaction
> > controlled externally.
> >
> > Does this mean the tx.rollback() was not performed?
> >
>
> Yes I think so. I suspect the begin was also not performed. I haven't used
> that external transactions setting before. Is this a setting you know that
> you need to have active? If not, the simplest thing to do would be to turn
> that off. Otherwise I think you need to handle this transaction start and
> end outside of the Cayenne APIs.
>
>
> >
> > On Fri, Nov 8, 2024 at 5:38 PM John Huss <johnth...@gmail.com> wrote:
> >
> > > I do manual transaction handling like this:
> > >
> > > TransactionFactory txFactory =
> > >
> CayenneRuntime.getThreadInjector().getInstance(TransactionFactory.class);
> > > Transaction tx = txFactory.createTransaction();
> > > tx.begin();
> > > try {
> > > // do work
> > >
> > > context.commitChanges();
> > > tx.commit();
> > >
> > > } catch (Exception e) {
> > > tx.rollback();
> > > throw e;
> > > }
> > >
> > > On Fri, Nov 8, 2024 at 5:21 PM Christian Gonzalez <
> > > christian.gonza...@smartscrubs.com> wrote:
> > >
> > > > Also forgot to mention but the runtime is configured with external
> > > > transactions enabled.
> > > >
> > > > On Fri, Nov 8, 2024 at 4:14 PM Christian Gonzalez <
> > > > christian.gonza...@smartscrubs.com> wrote:
> > > >
> > > > > Hello, I am currently using cayenne 4.2 and am running into some
> > issues
> > > > > when committing my changes. We have an application that uses a
> single
> > > > > object context to do all the necessary changes we want to save to
> the
> > > > > database and then when the user clicks the save button we call the
> > > > > objectContext.commit(). The issue is that if a commit exception
> > happens
> > > > > during this process we end up with half committed data as the
> > > transaction
> > > > > doesn't get rolled back. From what I understand, if I were to
> capture
> > > > > the exception and do objectyContext.rollbackChanges it would only
> > > remove
> > > > > the changes to the object context, not actually rollback the
> changes
> > in
> > > > > the database. I also tried a mixture of this example provided for
> > > > > transactions in the cayenne documentation
> > > > > <https://cayenne.apache.org/docs/4.2/cayenne-guide/>and this
> example
> > > at
> > > > > the bottom from apache
> > > > > <
> > > >
> > >
> >
> https://nightlies.apache.org/cayenne/docbook/index/persistent-objects-objectcontext.html
> > > > >.
> > > > > Essentially I'm calling the runtime.performInTransaction and inside
> > of
> > > > the
> > > > > TransactionOperation using the
> BaseTransaction.getThreadTransaction()
> > > > > method to get the transaction, then calling the
> objectContext.commit
> > > and
> > > > > after calling that method doing transaction.commit(). Iif an
> > exception
> > > > > happens I call transaction.rollback() but once it's all done I
> still
> > > see
> > > > > the changes that were sent before the exception present in the
> > database
> > > > and
> > > > > when I look at the logs of the SQL that gets sent I don't see a
> > > > transaction
> > > > > started. My question is am I using the transaction correctly or how
> > do
> > > I
> > > > > get all the changes in the object context to be reversed if an
> > > exception
> > > > > happens?
> > > > >
> > > >
> > >
> >
>
