Killing derby/tomcat

[Walter Rogura <mi...@sudus.eu>]

Hi folks,

I have a project running, where I use tomcat 6 and derby 10.4. Both work
quite fine together. But I observed that after changing db entries via
the web-interface and tomcat get accidentally killed not all changes
have been considered.

In my case I have a person A, B and C. B and C report to A, so they
refer to A. Cascading considers that if A gets removed that the
references of B and C should be removed and set to NULL.
And indeed, after removing A and stopping tomcat, the references of B
and C are set to NULL.
But, when removing A waiting a few seconds and killing tomcat, B and C
still refer to A.

Maybe this is intended by the derby team due to performance reasons, but
it is not useful in my case, since tomcat get killed quite often and I
always have to clean up the db afterwards.

I'm really eager to know why that is so and what I could do to change
it.

Thank you very much,
Walter

Re: Killing derby/tomcat

["Dag H. Wanvik" <Da...@Sun.COM>]

Walter Rogura <mi...@sudus.eu> writes:
> Hi folks,
>
> I have a project running, where I use tomcat 6 and derby 10.4. Both work
> quite fine together. But I observed that after changing db entries via
> the web-interface and tomcat get accidentally killed not all changes
> have been considered.
>
> In my case I have a person A, B and C. B and C report to A, so they
> refer to A. Cascading considers that if A gets removed that the
> references of B and C should be removed and set to NULL.
> And indeed, after removing A and stopping tomcat, the references of B
> and C are set to NULL.
> But, when removing A waiting a few seconds and killing tomcat, B and C
> still refer to A.

Are you able to see how this integrity constraint is mapped to Derby
schema? Does the mapping use a REFERENCES .. ON DELETE CASCADE clause?

Dag