From: marc f. <mar...@jb...> - 2001-06-14 18:45:11
|
|Yeah, double serialization, but isn't keeping an isUpdated table just |overkill and a pain in the ass? Maybe not I guess, set the flag |to true for |each entity after you do the finder synch. Set it to false after every |method invocation that could possibly change the state of the entity. |You're right, I'll put this in....Thanks for discussing this issue. the idea that you are aware of the impact of the feature. Right now I would recommend XP meaning put the feature you really need and try to minimize the amount of code you can screw up. In other words, don't commit that last "tuned" feature, if you are not absolutely sure about the new "updates" let's try without it since the case you describe will be minimally used (and therefore we won't pay the price and if you use it, using isModified and tuned updates will give the same result) so screw that feature if keeping the isUpdated table is overkill. |On another note, I view this change not as a "feature", but rather a bug |fix, an ejb spec violation. It's kind of significant when I think |about it. hmm i don't remember that feature from 1.1 days, sounds like a 2.0 feature. As such it is great that you add it to be compliant. And sure sure, it is the most important feature of the server ;-) |If you modify an entity within a transaction, a subsequent finder query |should be able to pick up the entity change. The example from before, |should work, but doesn't with the current version of jboss. Also common |sense dictates it should work as well, (at least in my messed up brain). ummmm that I really don't agree with, that database guys can see the change outside the commit within the same transaction seems kind of funky to me... but it is in the spec so... |BTW, thanks for reviewing all this stuff. you bet, keep it simple... marcf |