> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of marc
> fleury
> Sent: Thursday, June 14, 2001 3:50 PM
> To: [EMAIL PROTECTED]
> Subject: RE: [JBoss-dev] No storeEntity before ejbFind<METHOD>
>
>
> |I have been working with databases for a long time,
> |and particularly with Oracle, I am not aware that this
> |can happen, whether in transaction or not, before
> |commit, nobody can see the updated table period in the
> |database..
>
> well that is my point precisely, it seems to imply that the
> updates "before
> the commit" are seen by connections enrolled in the SAME
> transaction THROUGH
> THE DATABASE.... and frankly I am a bit skeptical as to the level of
> support for these features in the db or even if they exist at all or are
> just "wishful features" (heck they don't even support 2pc and xa right)...
>
Entities(of the same type) in the same transaction will be using the same
connection correct?
> so this smells of "teen spirit" to me... by requiring "inflight"
> visibility
> of the changed records they put a difficult requirement on the db drivers
> and I don't see it working well.
>
Can't see how this effects the db drivers. Why would all this state be held
by the drivers? Can somebody elaborate?
> They could have just required lock steps, as in first commit the changes
> (and the db can follow that semantic) and then issue your findBy as just
> another query...
>
> I am no db expert (they are rare these days) but it strikes me as a
> misguided requirement.
>
> Bill for example couldn't you get the same functionality with the
> serialiazed commits? Is this functionality that you couldn't get
> otherwise?
No, we can't get the functionality from serialized commits, nor could we get
it otherwise. The code could probably be re-organized, but we're under the
gun time wise so it would have to wait.
Please read the example again.
begin transaction
bean.flag = true
findByFlag where flag = true
end transaction
> you are the first one to require this feature (and you are savvy enough to
> scratch your itch so that is cool but still I wonder...)
>
Actually, it's not really me who requires it, but our application(in a few
places here and there). I'm responsible for the AppServer. If somebody
asks, "I have a problem Bill, is it a JBoss bug?". I look into it and tell
them "No, it's not a JBoss bug, change your code." or "yes, its a JBoss bug,
I'll try to fix it." This "storeEntity before ejbFind" is a perfect example
of this scenario. (BTW, JBoss bugs are a rarity).
(Hey, it used to be "Bill, this worked in WebLogic, why doesn't it work in
JBoss?", but we're over that hump finally. BTW, those questions were always,
and I mean always, JBoss config problems. Never actual bugs, just to make
things clear.)
> but the REAL question is "is it true that you cannot see changed
> tables from
> a connection participating in the SAME transaction that changed it in the
> first place?"
>
I'm no DB expert, nor even close, but here are my assumptions....
1. Entities of the same type will share the same connection if they are
within the same transaction. Correct?
2. It is not possible to have more than one DB non-nested concurrent
transaction within a connection. Correct?
3. A DB transaction cannot be accessed between multiple connections.
Correct?
4. And, yes a connection participating in the SAME transaction can view
updates.
All in all, us needing this ejb 2.0 spec required feature may be bad
programming, but as of right now, I'm not convinced that it is. Convince me
otherwise. I'm pretty open-minded and I'll admit to being wrong.
Also, I apologize for the unprofessional "That's BS" statement I made to
Gina before.
Regards,
Bill
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
