I really disagree on locking the code in cvs. I'd prefer a solid test suite
that tests this stuff backward and forward so that if somebody checks in
bogus code, we will know who it is. We should encourage people to look at
this code. The more eyes the better this code will be and get. Locking the
code in CVS just discourages people from taking a look at it.
BTW, I'll fix this stuff as soon as possible(I know the fix), I keep on
getting pulled for stuff at the "real" job.
Bill
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of marc
> fleury
> Sent: Tuesday, August 07, 2001 11:12 AM
> To: [EMAIL PROTECTED]
> Subject: RE: [JBoss-dev] synchronizeEntitiesWithinTransaction, null pk &
> remove
>
>
> |bill,
> |
> |between you and I,
>
> It was between Bill and I and then I send the message to everyone.
>
> I am not even going to apologize for this since in fact it is better this
> way.
>
> I will repeat that NO-ONE should touch the interceptor sync stuff (the 3
> core interceptor classes) without a deep review from top developers first.
> I really recommend locking the code in cvs if that feature exists. It was
> the Locking-waiting buzy wait bug, it was a ton of missed locks it is a
> nightmare, even for me (who spends most time in it). don't touch
> it please.
>
> So it is better that it is in the open
>
> marcf
>
> |this is typically the type of problem I want to avoid
> |with the core container interceptors. I know (pretty sure) I didn't miss
> |something as basic as that and obviously it wasn't you. If it is
> |me then it
> |only makes the following point even more true.
> |
> |I put "you must be this tall to ride the dragon" messages in the
> |code but it
> |seems to have no effect in fact it seems to attract more people
> wanting to
> |take the challenge. You and I know the nightmare that solid synch is (I
> |almost went crazy with it) so it *enfuriates* me when someone comes and
> |changes it without paying attention. Can you track down the
> change (still
> |compiling painfully in RH) and let me know and will send a "friendly
> |reminder privately". :( It could very well be me because I
> honestly don't
> |remember.
> |
> |thanks for being on top of this, I am just tired of going back
> and back to
> |it. It is a waste of our time.
> |
> |we should do it once and for all and then **lock** the 3 classes
> |code in CVS
> |:)
> |
> |marcf
> |
> ||-----Original Message-----
> ||From: [EMAIL PROTECTED]
> ||[mailto:[EMAIL PROTECTED]]On Behalf Of Bill
> ||Burke
> ||Sent: Tuesday, August 07, 2001 10:34 AM
> ||To: [EMAIL PROTECTED]
> ||Subject: RE: [JBoss-dev] synchronizeEntitiesWithinTransaction, null pk &
> ||remove
> ||
> ||
> ||
> ||
> ||> -----Original Message-----
> ||> From: [EMAIL PROTECTED]
> ||> [mailto:[EMAIL PROTECTED]]On
> Behalf Of Jason
> ||> Dillon
> ||> Sent: Monday, August 06, 2001 9:19 PM
> ||> To: [EMAIL PROTECTED]
> ||> Subject: [JBoss-dev] synchronizeEntitiesWithinTransaction, null pk &
> ||> remove
> ||>
> ||>
> ||> I am running into a problem with entity bean removal where the
> ||pk is null,
> ||> which causes most everything passed (and including)
> ||> Application.synchronizeEntitiesWithinTransaction() to fail
> (called from
> ||> EntityContainer.remove()).
> ||>
> ||
> ||The person who moved synchronizeEntitiesWithinTransaction forgot
> |to perform
> ||that same logic that is EntitySynchronizationInterceptor.storeEntity. I
> ||should have caught this when I reviewed the code. Sorry, I'll
> fix it now.
> ||
> ||BTW, pk get's set to null when a remove() is called.
> ||
> ||Bill
> ||
> ||
> ||
> ||_______________________________________________
> ||Jboss-development mailing list
> ||[EMAIL PROTECTED]
> ||http://lists.sourceforge.net/lists/listinfo/jboss-development
> |
> |
> |_______________________________________________
> |Jboss-development mailing list
> |[EMAIL PROTECTED]
> |http://lists.sourceforge.net/lists/listinfo/jboss-development
>
>
> _______________________________________________
> Jboss-development mailing list
> [EMAIL PROTECTED]
> http://lists.sourceforge.net/lists/listinfo/jboss-development
>
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
