Subject | Re: [Firebird-Java] Re: jaybird glassfish connection pooling |
---|---|
Author | Mark Rotteveel |
Post date | 2011-12-08T21:18:42Z |
On 18-11-2011 14:57, Mark Rotteveel wrote:
It took a while, but I finally identified the problem. It is not in
Jaybird, but in the interaction between the DatabaseException thrown by
EclipseLink, and the way Flex serializes the exception.
I will close the ticket JDBC-199, because there is nothing we can change
in Jaybird to prevent this.
You may want to see if you can configure Flex to behave in a different
way when an Exception occurs or configure it not the serialize the
entire exception or something like that, other than that: I think you
could try to file a bug with EclipseLink.
I just posted this to your ticket
http://tracker.firebirdsql.org/browse/JDBC-199:
The problem is that when the unique constraint violation exception is
thrown by EclipseLink, the exception (DatabaseException) contains
detailed information on the cause, including the SQLCall object, which
contains an InsertObjectQuery which contains an object of class
RelationDescriptor.
When Flex receives this exception, it serializes the exception using a
custom serialization protocol. And during that serialization it will
serialize everything it considers a bean property. During that
serialzation it calls a method called getInheritancePolicy() on the
RelationDescriptor. This method has a side-effect, where it will create
a new InheritancePolicy if the current value is null. The problem is
that Movie does not have inheritance, so the inheritancePolicy should
remain null.
If after this exception you create a new object, it will refresh the
Movie list, and now due to inheritancePolicy being non-null, it calls a
number of methods it should not actually call for this object with the
NullPointerException as a result.
In other words: This is not a problem in Jaybird, but in the interaction
between how Flex handles the Exception, and the way EclipseLink handles
that inheritancePolicy property. I would consider this a bug (or at
least a deficiency) in EclipseLink, so I would advise you to file a bug
with them.
Mark
--
Mark Rotteveel
> On Fri, 18 Nov 2011 13:56:13 -0000, "raphael_bourges"Hi Raphaƫl,
> <raphael_bourges@...> wrote:
>> Hi,
>>
>> I have just tried with EclipseLink 2.3.1 but the same error occured.
>
> Ok, then I will need to dig deeper.
It took a while, but I finally identified the problem. It is not in
Jaybird, but in the interaction between the DatabaseException thrown by
EclipseLink, and the way Flex serializes the exception.
I will close the ticket JDBC-199, because there is nothing we can change
in Jaybird to prevent this.
You may want to see if you can configure Flex to behave in a different
way when an Exception occurs or configure it not the serialize the
entire exception or something like that, other than that: I think you
could try to file a bug with EclipseLink.
I just posted this to your ticket
http://tracker.firebirdsql.org/browse/JDBC-199:
The problem is that when the unique constraint violation exception is
thrown by EclipseLink, the exception (DatabaseException) contains
detailed information on the cause, including the SQLCall object, which
contains an InsertObjectQuery which contains an object of class
RelationDescriptor.
When Flex receives this exception, it serializes the exception using a
custom serialization protocol. And during that serialization it will
serialize everything it considers a bean property. During that
serialzation it calls a method called getInheritancePolicy() on the
RelationDescriptor. This method has a side-effect, where it will create
a new InheritancePolicy if the current value is null. The problem is
that Movie does not have inheritance, so the inheritancePolicy should
remain null.
If after this exception you create a new object, it will refresh the
Movie list, and now due to inheritancePolicy being non-null, it calls a
number of methods it should not actually call for this object with the
NullPointerException as a result.
In other words: This is not a problem in Jaybird, but in the interaction
between how Flex handles the Exception, and the way EclipseLink handles
that inheritancePolicy property. I would consider this a bug (or at
least a deficiency) in EclipseLink, so I would advise you to file a bug
with them.
Mark
--
Mark Rotteveel