honestly?
I don't really care...
but if that is your thing, and it works, and it is spec compliant, then it
is definitely ok by me... :)
marcf
|-----Original Message-----
|From: [EMAIL PROTECTED]
|[mailto:[EMAIL PROTECTED]]On Behalf Of Bill
|Burke
|Sent: Thursday, June 14, 2001 4:50 PM
|To: [EMAIL PROTECTED]
|Subject: RE: [JBoss-dev] No storeEntity before ejbFind<METHOD>
|
|
|
|
|> -----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
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
