Ok, I'll do that! :-D
Andrus Adamchik escribió:
It's not that expensive (each context attaches to a shared stack) and
looks like the best strategy in your case.
One possible optimization is to use a single shared DataContext for
read-only operations, and create a new DataContext for each operation
that is expected to modify and commit the objects. It is only possible
of course if you have any "read-only" operations at all.
Andrus
On Jan 7, 2008, at 5:30 PM, Álvaro Martínez wrote:
Thanks, Andrus and Philip
The threads I'm talking about are created from many sources and for
different reasons. Not of all them are triggered in response to
"something". There are also watchers, periodic tasks... So I can't
map data contexts to some particular condition.
So then I have to create one data context per operation (that means a
set of actions). Is this expensive? We are developing a heavy loaded
cluster of servers, so it's important.
Thanks again!
Andrus Adamchik escribió:
Hi Álvaro,
It is hard to give a precise advice on multithreading without
knowing the nature of your application. So here is a few general notes:
* DataContext instance is your isolated area for making in-memory
changes to objects that will all be committed at once. So consider
using multiple contexts as appropriate. Cayenne docs recommend
various common patterns, such as DataContext per session (i.e. each
user has a dedicated context), DataContext per request, or
DataContext per application (in a read-only app). You can also
devise your own approach, if none of the above fit your needs. All
you need to know here is that multiple threads *reading* from a
shared DataContext is ok, but multiple threads *writing* to a shared
DataContext is not ok.
* In a rare case if you really need multiple threads to work off of
the same context, consider using a dedicated nested DataContext for
each atomic object modifications.
Andrus
On Jan 7, 2008, at 2:44 PM, Álvaro Martínez wrote:
Hi, I've been working for a while with Cayenne but never realized I
had a problem... until I got a weird exception.
The fact is that I had been using context.newObject() and
context.commitChanges() to create new rows in the database. But my
application works with many threads, so global commits can (and in
fact do) interrupt normal creation of objects. Thread A and Thread
B are creating objects and filling their fields, but then B commits
all and A throws a validation exception because mandatory fields
are missing.
How could I commit only one object?
Thanks,
Álvaro from Spain (Push the button Inc.)
