Tom Chen

Hi,
I deployed the .ear file on Weblogic 6.1 and it didn't work!
TOM
[ January 18, 2003: Message edited by: Tom Chen ]

Hi Rich,
Thank you for your reply.
In the example code, it rollback the Container Manage Transaction by calling context.setRollbackOnly(). The same as what you say. However it still cannot rollback unless create the java.sql.Connection in the business method instead of create it once in the ejbCreate() and store it in the instance variable. Why?
You can download the tutorial and take a look at the example code.
BTW, there's another way to let the transaction rollback by throwing a System Exception-- EJBException which is a RuntimeExcepion.

Thank you,
Tom
[ January 18, 2003: Message edited by: Tom Chen ]

Hi,
Does anyone know something about this problem?
Thank you in advance,
Tom

Hi,
Does anyone ever deploy and test the CMT stateful session bean example from Sun J2EE Tutorial(the source code is in the directory of j2eetutorial\examples\src\ejb\bank)?
I've tried it and found the transaction cannot rollback!(By setting the balance of checking account to less than 40).
In the code provided by Sun, it creates a java.sql.Connection in ejbCreate() and stored it as a instance variable. Then use this connection in the transactional business method transferToSaving().
I try to modify to this way then the transaction works well(can rollback): create java.sql.Connection in the business method transferToSaving().
I wonder whether my solution is correct way to write CMT session bean or something wrong with my deployment( I deployed the bean on weblogic server 6.1)
Thank you,
Tom

Hi,
In a BMT session bean, why I can use java.sql.Connection.commit() method between UserTransaction.begin and UserTransaction.commit on Weblogic Server6.1:
1)UserTransaction.begin()
2)...
3)java.sql.Connection.commit()
4)UserTransaction.commit()
Is it because the JTA transaction isn't begin yet? If this is the case, how to check whether the JTA transaction begin and why it doesn't begin?
Thank you,
Tom
[ January 15, 2003: Message edited by: Tom Chen ]

Hi Frankie,
I finally found that it is because Primary Key is not specifed for the table. I think Primary Key is a must for the row level locking.
Thank you very much,
Tom
[ January 15, 2003: Message edited by: Tom Chen ]

Hi,
Two JDBC transcations are runned concurrently. They update the same table, but different records. Since they update different records, they should not affect each other. But the result shows that the 2nd transaction cannot continue until the 1st transaction finished.
Isolation level is set to Read Commited. I'm using weblogic 6.1 + db2 7.1
Transaction 1
1)transcation begin
2)update record1
3)(let the thread wait for 60 seconds on purpose....)
4)update rec2
5)transcation end
Transaction 2
1)transcation begin
2)update rec3
3)update rec4
4)transcation end
Can anyone explain why would this happened? How to fix this problem?
Thank you
Tom

Hi,
Does anyone have some more idea about this problem?

Thanks in advance,
Tom

Originally posted by Kyle Brown:
I seem to remember (but be sure -- ask a DBA) that DB2 actually has a fairly small set of row locks that it uses -- you may want to look into increasing the number of available locks...
Kyle

Hi,
I believe that the lock level of the table is set to row-level. The table is so samll that it never reach the limitation of available locks.(Only 4 records, it's just for testing).
The problem remains the same. Why? Why?
Thank you again,
Tom

Hi Kyle,
Yes, I agree with you that the database is not config support row-level locking. I'm using weblogic 6.1 + IBM DB2 v7.
However, after I config the table:
Alter table account locksize row
and run the two transaction again, the result remains the same: When a transaction updating a record, it seems to lock the whole table.

Thank you,
Tom
[ January 12, 2003: Message edited by: Tom Chen ]
[ January 12, 2003: Message edited by: Tom Chen ]
[ January 12, 2003: Message edited by: Tom Chen ]

Hi,
Does anyone know something about it?
Thank you,
Tom

Hi,
Two transcations are runned concurrently. They update the same table, but different records. Isolation level is set to Read Commited. The transaction is implemented as a stateless CMT session bean.
(1)
transcation begin
update record1
(let the thread wait for 60 seconds on purpose....)
update rec2
transcation end
(2)
transcation begin
update rec3
update rec4
transcation end
Result:
the 2nd transcation need to wait for the 1st one.
Can anyone explain why would this happened? How to fix this problem.
Thank you
Tom
[ January 12, 2003: Message edited by: Tom Chen ]
[ January 12, 2003: Message edited by: Tom Chen ]

Originally posted by Chris Mathews:
A Datasource hands out JDBC connections and in WebLogic it is backed by a Connection Pool. This the preferred method of retrieving JDBC connections in J2EE since it makes code easier to move between Application Servers (ie. all app servers support datasources).
A TXDatasource can be involved in a distributed transaction, a regular Datasource cannot. If you are using container managed transactions or JTA then you must use a TXDatasource.

Hi,
Where can I find more information about the difference between TXDatasource and Regular Datasource? Why does Weblogic provide two different types of datasource? My understanding is the Regular Datasource is the subset of TXDatasource, so there's no need to provide the Regular Datasource. As I know, Websphere only proved one type of Datasource which provide transcation support.
Any comments,
Tom

8. At what point, precisely, in the life-cycle is a container-managed entity bean considered created?
A. Immediately prior to the execution of its ejbCreate() method
B. Immediately after the execution of its ejbCreate() method
C. After the CMP bean's data has been committed to the underlying persistent datastore
D. During the execution of its ejbPostCreate() method
Answer provided: B
However my answer is C. Let's assumpt that we have a transaction which create two entity beans:
1)transcation start
2)create EntityA -- call ejbCreate() of EntityA
3)create EntityB -- call ejbCreate() of EntityB
4)commit or rollback
after step 2) -- calling ejbCreate() of EntityA sucessfully, we may have error while calling ejbCreate() of EntityB, then the container would rollback the creation of EntityA. So from this point of view, the provided answer B is incorrect.
Welcome comments,
Tom

Originally posted by RAEES UZHUNNAN:
Please some one give me some thoughts about this

Hi Raees,
I've been studying the Pet Store 1.3 these days. I'm very interested in your topic. Would you please explain more detailed for your question? Which version of Pet store you are talking about?
My understanding is that the number of stateless session bean in the pool can be confiugred in the application server. You can configure your pool size of catalog statless session bean based on the number of clients, server capability, quatity of catalog etc.

Tom
[ January 07, 2003: Message edited by: Tom Chen ]