Hi All
Update: There was a primary key constraint missing on the
database for u3 (wondering how i missed it, anyways sorry about that
confusion). So this explains why the duplicate row insert was going
through fine.
Now the question is shouldn't eclipselink throw an exception when
one writes to a read only mapping?
I guess that with the primary key check in place, cache corruption
will not happen (can there be another usecase that I am missing?).
Otherwise accidental write to a read-only mapping corrupts the cache
so that it is not in sync with the database.
Thanks
Rohit
On 5/4/2011 7:12 PM, Rohit Banga wrote:
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
_______________________________________________
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
|
