jdbc2 pm and dirty flags

triathlon98 May 1, 2005 5:38 PM

I am using Jboss 4.0.1RC2 and was comparing sql statements generated when using "instance-per-transaction" compared with "cmp2.x jdbc2 pm" container configurations.

I see that the jdbc2 configuration incurs less select sql queries (cache works, great), but is also causes more update statements.

I use the following configuration :

 <container-configuration extends="cmp2.x jdbc2 pm">
 <container-name>IC-trace Entity Bean</container-name>
 <call-logging>false</call-logging>

 <sync-on-commit-only>true</sync-on-commit-only>
 <insert-after-ejb-post-create>true</insert-after-ejb-post-create>
 <call-ejb-store-on-clean>false</call-ejb-store-on-clean>
 </container-configuration>

It now generates an update statement after each insert, even though nothing has changed in the entity. Also, the update statement always seem to update all fields, not just the changed fields.

Is the dirty field handling different for these containers?
Is there a way (configuration) to make sure the update behaviour is the same as for the other persistence managers?

Thanks,
Joachim

1. Re: jdbc2 pm and dirty flags

triathlon98 May 2, 2005 11:58 AM (in response to triathlon98)

I have further investigated this problem and the problem has nothing to do with dirty flags, but rather the sync-on-commit-only flag which has no effect.

When using p6spy to check the SQL statements, I see that the insert only contains values for some of the fields, and the update completes the fields. These fields are only set in the SFSB which creates the entity.

Sam question though. Is there any way to tune this? Would make a huge performance difference for my tests.

Thanks,
Joachim
Actions
2. Re: jdbc2 pm and dirty flags

aloubyansky May 5, 2005 8:25 AM (in response to triathlon98)

The persistence managers are of course completely different.
Dirty checking is different. UPDATE includes all the fields in the jdbc2 pm.
In jdbc2 pm you can delay INSERT until commit time using insert-after-ejb-post-create set to FALSE.
Actions
3. Re: jdbc2 pm and dirty flags

triathlon98 May 6, 2005 11:40 AM (in response to triathlon98)

Great, that option speeds it up a little more (about 20% in a real world test).

Unfortunately though , I seem to occasionally have uniquness violations on the pk for the n:m link tables. I will investigate further to see if I can build a testcase for this.

Thanks,
Joachim
Actions

Go to original post