Remove problem

[radl01]

Hi all,

simple question: Why JBoss calls update statement before remove. This cause problem for me, because JBoss try to store null values to not null columns in update statement.

I use JBoss 3.2.2.

I have one releation between A:B as 1:n and I try to remove one record from B (b.remove().)

Jan

[marcosjara]

I have the same problem!!!

Can any body explain why Jboss do it!

[marcosjara]

I found an option in standarjboss.xml configuration file <sync-on-commit-only>

I set this option to true but nothing happen.

[juha]

Looks like a spec requirement:


10.5.3

The container synchronizes the instanceÂ’s state before it invokes the ejbRemove method.
This means that the persistent state of the instance at the beginning of the ejbRemove
method is the same as it would be at the beginning of a business method

[vprise]

Looks like a spec requirement:

<blockquote>
<b>10.5.3</b>
<br>
The container synchronizes the instance’s state before it invokes the ejbRemove method.
This means that the persistent state of the instance at the beginning of the ejbRemove
method is the same as it would be at the beginning of a business method
</blockquote>

I'm sorry but I don't see how setting a CMR value to null which is illegal and undermining relational integrity of the database can be understood from that statement.

Maybe I'm dense but it just says that you need to synchronize the instance state so everything will be updated in memory, but IMO ejbRemove should just fail if a CMR pointing at it has a foreign key and it should not try to second guess the programmer by setting it to NULL!

Even if the spec somehow demands this behaviour it is just plain stupid and a REAL workaround should exist, right now people in the forms are setting fields to "NOT NULL" and using insert after post create which is REALLY not according to the spec in order to get the behaviour that makes sense.

IMO this bug makes CMR almost useless, without the patchy workaround mentioned above you would have a serious race condition on your hands which could cause database corruption.

[juha]

So file a bug report, if there's a workaround you'll hear about it.

[vprise]

So file a bug report, if there's a workaround you'll hear about it.

I searched back then and there is a bug report.
It was claimed that this is intended functionality which IMO is just ridiculous and huge missinterpretation of the spec.
As I have specifically stated I have a workaround but its patchy and it is NOT what I am interested in. Sure I can solve this in code but then I will have my own forked version of JBoss which again is not what I need.
I just don't understand how something like this can be considered a "feature"? Who could possibly be interested in functionality that corrupts your database layer?