Hi Louis-Frederic,
you are right that all objects are cached by castor as without this long
transactions would not work. What causes problems in your usecase is
that castor returns new copies of the cached objects for every transaction.
At the moment I have no idea how you can work around the problem or how
this can be resolved by castor.
If you could provide me with some more information
- mapping of A and B
- do you need list of B's on A
- do you need list of A's on B
I would try to find a work around.
Regards
Ralf
Louis-Frederic Huppé St-Hilaire schrieb:
Hi and here’s my question:
Let’s say you have two model objects, A and B, in a many-to-many
relationship. What you want to do is to let a user see and potentially
edit all instances of A found in the database.
This spells “long transaction” so you load all instances of A in a
long transaction context and let the user edit them. In the dialog
allowing for the edition of instances of A, a list of instances of B
found in the database is shown so that the user can associate any of
them to the currently edited instance of A. In order to retrieve that
list, the database has to be queried in a new transaction.
The problem is that the objects created in that second transaction are
completely different than those created in the first part of the long
transaction. Some of these objects happen to represent instances
already represented by objects found under the currently edited
instance of A. This translates into DuplicateIdentityExceptions being
thrown when the update() method is called on the instance of A after
new relations to instances of B have been added.
Is there any way around that problem ? Is there any way, when loading
the list of instances of B, to make JDO realize that some of the
objects it is about to create already live in a cache somewhere which
is associated to the current long transaction ? That cache has to
exist since it is used for dirty checking according to the documentation.
Otherwise, are we to understand that all objects that may potentially
be involved in modifications in the context of a long transaction must
be loaded all at once ? For simple scenarios, this is not too bad, but
in the practical case I am facing, this would basically involve
loading the whole database.
Thanks in advance for the tips,
LF
-------------------------------------------------
If you wish to unsubscribe from this list, please
send an empty message to the following address:
[EMAIL PROTECTED]
-------------------------------------------------
