Hello,
this is the normal behaviour since the standard container configuration is
the "A" option of commit, which means that we assume that the beans are the
only living representation of the entity in db and the sole point of access.
In your case you break that since you "manually insert SQL Plus" stuff,
*you* are the second point of access ;-). You need to specify the "B"
commit option for your beans if that is the case.
What it does is that in the first case the container doesn't reload (he *is*
the state holder) while in the second case he does reload on start of
transaction.
This is why you don't see your change.
Bottom line: only point of Acess: OPtion A. Many points of access in DB
option B
marc
|-----Original Message-----
|From: [EMAIL PROTECTED]
|[mailto:[EMAIL PROTECTED]]On Behalf Of Nortje, Andrew
|Sent: Saturday, November 18, 2000 1:47 PM
|To: 'jBoss'
|Subject: [jBoss-User] ejbLoad & ejbStore problem
|
|
|I have an interesting ejbLoad and ejbStore problem. I have a number of
|session and entity beans deployed, all entity beans are bean managed. It's
|the age old shopping mall thing. So essentially I have a Customer session
|bean with a buy method. The buy method starts a transaction - I manually
|control the transactions. Everything works great, correct amounts are
|credited and debited, transactions are begun and committed.
|
|While testing, the customers account ran out of money, so I manually
|increased the balance using SQL Plus, we are using Oracle. I did
|remember to
|commit my update in SQL Plus (I have learnt my lesson). I then ran my test
|program again and kept getting an insufficient funds exception
|even though I
|had just updated the account balance manually. I finally figured out the
|following was happening.
|
|I did an ejbFind( ) which returned a new Account entity bean with the
|correct updated balance, which I had just updated in SQL Plus. jBoss then
|went and did an ejbStore() with an old Account bean instance in the pool,
|which had the old Account balance, and which then reset the balance.
|
|If the previous transaction committed successfully why does the container
|(jBoss) do an ejbStore. I should rather do an ejbLoad() or nothing at all.
|
|If I shutdown and restart jBoss there are no 'rogue' beans out there to
|'mess things up', obviously, and everything works fine. What am I doing
|wrong? I undestand transaction isolation can be quite complex. Do I need to
|set a transaction attributes for each method in my entity beans?
|
|The debug output from jBoss and my code is... as you can see the Balance
|should be 60 but is reset to 5
|
|[InternalAccount] New AccountBean
|[InternalAccount] New AccountBean
|[InternalAccount] ejbFind( entity ) InternalAccount
|com.uni.account.InternalAcco
|untBean@4204
|[InternalAccount] SQL: Select * from Account where ENTITY_ID=3 AND
|ACCOUNT_ORDE
|R = 0
|[InternalAccount] Result = org.jboss.minerva.jdbc.ResultSetInPool@b8a47
|[InternalAccount] Balance = 60.0
|[InternalAccount] ejbStore() InternalAccount
|com.uni.account.InternalAccountBean
|@524e3f
|[InternalAccount] InternalAccountBean ejbStore() called
|[InternalAccount] ID is 3
|[InternalAccount] SQL: Update Account set ENTITY_ID = 3, BALANCE =
|5.0 where
|ENT
|ITY_ID = 3
|[InternalAccount] SQL: Update Account set ENTITY_ID = 3, BALANCE =
|5.0 where
|ENT
|ITY_ID = 3 1 updated
|[Customer] Cart value = 55.0 Balance = 5.0
|[InternalAccount] ejbStore() InternalAccount
|com.uni.account.InternalAccountBean
|@524e3f
|[InternalAccount] InternalAccountBean ejbStore() called
|[InternalAccount] ID is 3
|[InternalAccount] SQL: Update Account set ENTITY_ID = 3, BALANCE =
|5.0 where
|ENT
|ITY_ID = 3
|[InternalAccount] SQL: Update Account set ENTITY_ID = 3, BALANCE =
|5.0 where
|ENT
|ITY_ID = 3 1 updated
|
|
|
|--
|--------------------------------------------------------------
|To subscribe: [EMAIL PROTECTED]
|To unsubscribe: [EMAIL PROTECTED]
|Problems?: [EMAIL PROTECTED]
|
|
--
--------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Problems?: [EMAIL PROTECTED]
