Hi Chris
I forgot to mention that direct-to-field mapping for a3 is set to
read only. So what happens when we try to write to a read-only
mapping. Shouldn't there be an exception when I try to write to it
or is the value just ignored. Is cache corruption expected in this
case?
I am actually catching Exception and logging an error message. Since
no error is logged, I can assume no exception is being thrown.
Besides here is the Eclipselink log which suggests that everything
went fine.
[EL Finer]: ClientSession --commit transaction
[EL Finest]: ServerSession --Connection released to connection
pool [default].
[EL Finer]: UnitOfWork --end unit of work commit
[EL Finer]: UnitOfWork --release
unit of work
[EL Finer]: UnitOfWork --release
unit of work
[EL Finer]: ClientSession ---client released
If this sounds perplexing I will try to write a stand alone program
ASAP to reproduce the issue.
Thanks
Rohit
On 5/4/2011 6:29 PM, Christopher Delahunt wrote:
Hello Rohit,
1) One of the mappings will need to be marked as read-only - you
cannot
have two writable mappings to the same U3.a3 field. If one is not
marked as read only, please file a bug to have validation throw an
exception, detailing how you are adding both mappings for the
u3.a3
field.
2) This situation is not allowed in EclipseLink and the multiple
writable mappings for u3.a3 field has caused a cache corruption.
It
looks like e3 was cached using the 'a3_new_row' value from the
direct
to field mapping as this was available without processing, but
overriden on insert when the 1:1 mapping was processed since it
got
processed after the direct to field. That said, even if this was
mapped correctly and only one field was read-only, the application
still seems wrong. You cannot have two entities with the same
identity
in the same context. You will need to delete e2 in a separate
transaction before resurrecting it as e3, and would likely get an
exception had e3 not used the 'a3_new_row' for identity.
3) My understanding is that the database should throw an exception
on
the insert, so I I cannot say why you are not seeing exceptions.
Could
be that you have delayed constraint processing, or have a
try/catch
block or exception handler that is ignoring the exception.
Best Regards,
Chris
On 04/05/2011 8:25 AM, Rohit Banga wrote:
Hi All
I tried the following with eclipselink build 9156.
There are two tables u1 and u3. u1 has fields a1, b1 with a1 as
the
primary key and u3 has fields a3, b3 with a3 as the primary key.
There
is a DynamicType corresponding to both u1 and u3.
Create a target-one-to-one mapping from u1 to u3 with the u3.a3
as the
foreign key. Create a one-to-one mapping from u3 to u1 for the
back
reference.
Now let us assume that there is an entity (E1) of type u1 having
the
following values - a1='a1_val' and b1='b1_val'. The
corresponding
entity (E2) linked by the target-one-to-one mapping in a3 has
the value
a3='a1_val' (foreign key constraint) and b3='b3_val'.
I create a new dynamic entity (E3) of type u3 with
a3='a3_new_row' and
b3='b3_new_row'. Now I establish the link between E1 and E3 by
setting
the value of join attribute for both the one-to-one mappings to
the
respective entities. The following two SQL queries are generated
as a
result. uow.commit() does not throw an error.
INSERT INTO u3 (b3, a3) VALUES (?, ?)
bind => [b3_new_row, a1_val]
DELETE FROM u3 WHERE (a3 = ?)
bind => [a1_val]
The second query deletes the row inserted by the first query.
I have two doubts here:
1. I provided the value for a3 as 'a3_new_row'. This value is
ignored
to ensure that the foreign key is populated created properly. Is
this
expected behavior? Shouldn't eclipselink throw an error for such
a
situation?
2. After the transaction commits when I issue a ReadAllQuery
(with the
_expression_ specifying the value of the primary alone so that
there is a
cache hit). The value of a3 is returned as 'a3_new_row' and that
of b3
as 'b3_new_row'. If I restart my program so that there is no
cache in
place now, the ReadAllQuery (with a left outer join) obviously
does not
return any entity for u3 as there is no link between u1 and u3
in the
database tables. The row in U3 was deleted by the SQL above. Is
this a
bug or am I missing something?
3. The first INSERT should fail as I already have a row in u3
that has
the value of a3 (primary key) as 'a1_val'. Since the back
reference
one-to-one mapping has privately owned property set to false,
eclipselink did not issue a delete for the row that was already
existing. But in this case the INSERT should not go through
fine. I do
not see any exception in my eclipselink logs with logging level
set to
finest.
Thanks for your help!
--
Thanks and Regards
Rohit Banga
Member Technical Staff
Oracle Server Technologies
_______________________________________________
eclipselink-users mailing list
eclipselink-users@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipselink-users
--
Thanks and Regards
Rohit Banga
Member Technical Staff
Oracle Server Technologies
|
