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 migh
If you need manual transaction handling in one spot you can use the code I
provided earlier as a starting point. You wouldn't need to change the
setting for the whole CayenneRuntime.
On Wed, Nov 13, 2024 at 12:01 PM Christian Gonzalez <
christian.gonza...@smartscrubs.com> wrote:
> At some point w
Oh right I can just wrap the procedure in a transaction. I'll give it a
try. Thanks for the help.
On Wed, Nov 13, 2024 at 11:16 AM John Huss wrote:
> If you need manual transaction handling in one spot you can use the code I
> provided earlier as a starting point. You wouldn't need to change the
From the docs
(https://cayenne.apache.org/docs/4.2/cayenne-guide/#transactions):
If you are using Spring, EJB or another environment that manages transactions,
you’ll likely need to switch the Cayenne runtime into "external transactions
mode". This is done by setting the DI configuration prope
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 tr
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
messa
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 (Exceptio
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 a
Hi,
That sounds logical but the issue could be that the calling party is simply not
aware that the
called library is using cayenne.
This would mean that an application which is calling some library always should
clear
(and keep) the transaction. This is not very logical.
And what about the ot
On Jan 6, 2011, at 10:48 AM, Hans Pikkemaat wrote:
> One library calls the other one.
> The first one is using the iterated query to get some data. It will call the
> second
> library to process the data.
IMO this first library (iterator control code) should be the place that does
transaction
Hi,
After some investigation it comes down to two problems
1)
An example.
I have 2 libraries. One library calls the other one.
The first one is using the iterated query to get some data. It will call the
second
library to process the data.
This second library however is not aware of a iterated
Haven't thought about this scenario deeply... How about this:
In the simplest case you can keep your changes in the DataContext while
iterating over the result (DataContext by itself is not permanently bound to a
transaction). And then commit them after iteration is finished. This will work
if
On 23/09/2007, at 2:23 PM, Philip Copeland wrote:
Did you have an issue committing every "several thousand records".
What
would you do if it failed at that stage - did you figure out a way to
resume again at a known point? Handling large imports is never easy.
Initially we had some memory i
apache.org
Subject: Re: Transactions , Primary Keys
On 23/09/2007, at 8:26 AM, Philip Copeland wrote:
> The main problem I'm facing is that objects don't get written to the
> database (nor Primary Keys generated) unless we commit our
> transaction.
> What I'm wishing for is
On 23/09/2007, at 8:26 AM, Philip Copeland wrote:
The main problem I'm facing is that objects don't get written to the
database (nor Primary Keys generated) unless we commit our
transaction.
What I'm wishing for is a mode where all changes are made to the
underlying database - but not commit
15 matches
Mail list logo
