Son Java

Greenhorn
+ Follow
since Nov 23, 2001
Merit badge: grant badges
For More
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
0
Received in last 30 days
0
Total given
0
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Son Java

Is OPTION A applicable for BMP in Websphere?
Thanks
Alagan
Kyle,
I found one PQ45585: WebSphere Application Server fixes from IBM site to correct a serialization problem when using Oracle database in advanced configurations.
http://www14.software.ibm.com/webapp/download/postconfig.jsp?id=4000845&pf=AIX&v=5.1&e=&cat=&s=z
But it says it is a fix for websphere commerce suite 5.1 and plat form AIX. Can this be tried for Websphere3.5 on Windows NT?
Thanks
We are experiencing problems (ORA-08177 can not serialize exception during long transaction) during concurrent access from multiple transaction. We have all our Session and Entity Beans with
TX_ATTRIBUTE : TX_REQUIRED
ISOLATION LEVEL : TX_SERIALIZABLE
Persistance : BMP
Transaction : CMT
Is there KNOWN problem with Oracle databse-- basically the problem being that Oracle's isolation levels don't map well to the EJB specification.
I tried IBM web site for tech Support, this kind of bug not reported any where.
Could some one give some insight?
Thanks
Alagan
Kyle,
And when we tried changing Oracle 8.x database Transaction Serilaizable parameter to "TRUE", the ORA-08177 problem goes away. But Oracle recommends to keep the databse serializable parameter to "FALSE".
I checked up in IBM site for the ORA -08177 issued in Tech Notes and other forums. I could not fine any thing related to this.
I would appreciate if you could give your views.
Thanks
Kyle,
CACHING OPTION:
Thank you for your detailed response. I went thru your "Enterprise Java Programming with Websphere" book to understand different OPTIONS for Caching. I checked up my Websphere App server setting for all Entity Beans and they have the default setting of OPTION C. As per the recommendation, it looks, OPTION A should be used for Read Only Data and where container has exclusive access to the database used by the entity bean.
I am still not convinced the use of OPTION A which can not this option where I have to provide exclusive lock for individual client because it can not gurantee the correctness of the data.May be I have not understood it properly.
Is there any reason why OPTION is not implemented in Websphere. It appears that OPTION C and B are one and the same except OPTION B keeps the instance ready.
ISOLATION LEVEL:
Though I change my Websphere OPTION from C to A for my entity beans, I don't think it will solve "Oracle 8177 -Can't Serialize exception". IS this correct?
As you mentioned, to overcome Oracle isolation level problem, I am going to try by dropping all Entity Beans Isolation level to "TRANSACTION_READ_COMMITED" from "TRANSACTIO_SERIALIZABLE" for testing purpose.
Since Oracle has this data maping problem with EJB,It would have been nice to have an OPTION similar to A with data correctness so that we can drop the isolation level.
Thanks
Kyle,
Assuming that the container implements Option A or Option B and in the scenario of concurrent access from multiple transaction,
CASE 1: Does ejbLoad()acquires an exclusive lock on the instances' state in the database
(OR)
CASE 2: Does ejbLoad() acquire a shared lock and the instance is updated, then ejbStore() will need to promote the lock to an exclusive lock.
As per CASE 1, throughput of read-only transaction could be impacted
As per CASE 2, tt may cause deadlock if concurrently under multiple transactions.
In our application, during concurrent access from multiple transaction, We get 8177 - Can't Serialize Exception. We are using Oracle Database.
If WAS3.5 impelemnets Option A or B, is it possible to decide to go with CASE 1. I am afraid we get Can't Serialize Exception due to the CASE 2 situation.
And All our Entity Beans are BMP with CMT with TX_ATTRIBUTE: TX_REQUIRED and Isolation LEvel as Tx_Serializable.
Thanks
Kyle,
Thanks for your reply.
1) I read the EJB spec for Commit Options. We are currently using Websphere3.5 (and planning to migrate to WAS4 in near future). What is the option is implemented in WAS3.5? Is this option implemented by the container provider or it can be modified from option A to B or C by the App server adminstartor during deployment? How do we set the option in App Server?
2)In our application, we do not go thru entity bean for Read Only data. We directly call the Database from session Bean via prepared statements. What kind of caching can be implemented for the Read Only data from Session Beans.
Thanks
We are developing a large scale insurance project in J2EE with Swing Applet as Front End and EJB's at the middle tier.Server side call always goes thru session bean to entity bean for add and update. Reading is done from Session bean to database.
We have not yet implemeted any caching mechanism in the GUI as well in the server side.
I would appreciate if some one could give share their idea about practical implementation on caching both in server and GUI sideand point to some URL and sample implementation.
We are developing a large scale insurance project in J2EE with Swing Applet as Front End and EJB's at the middle tier.Server side call always goes thru session bean to entity bean for add and update. Reading is done from Session bean to database.
We have not yet implemeted any caching mechanism in the GUI as well in the server side.
I would appreciate if some one could give share their idea about practical implementation on caching both in server and GUI sideand point to some URL and sample implementation.
22 years ago