Win a copy of Murach's Python Programming this week in the Jython/Python forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic

Data Caching in EJB application  RSS feed

 
Son Java
Greenhorn
Posts: 9
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Kyle Brown
author
Ranch Hand
Posts: 3892
5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Well, with caching you are forced to use what your container provides on the server side in most cases. I suggest you read the section of the EJB specification that describes the difference between Option A caching, Option B caching and Option C caching.
In most app servers you simply want to let the server cache things on a per-transaction basis (this is called Option C caching, and nearly every server implements it). Some very long-lived objects that do NOT change you can instead cache using Option A caching. This will cache them for the lifetime of the application server -- the problem here is that if it changes underneath the application (in the database) it will not be refreshed (although some app servers have "timer threads" that will refresh the values every so often...).
In some cases where you have small, long-lived data that never changes, Option A would be overkill (just creating an Entity bean is actually overkill...) I'm talking about very simple things like lookup tables for codes, geographical locations, etc. I've described this approach in this article.
Kyle
------------------
Kyle Brown,
Author of Enterprise Java (tm) Programming with IBM Websphere
See my homepage at http://members.aol.com/kgb1001001 for other WebSphere information.
 
Son Java
Greenhorn
Posts: 9
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
 
Son Java
Greenhorn
Posts: 9
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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 Brown
author
Ranch Hand
Posts: 3892
5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Son Java:
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?

Ah. Then this is easy. This is actually all covered in my book WebSphere implements Option A (called "Exclusive Mode") and Option C (called "Shared mode").

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

I will refer you to the article above where I talk about caching read-only data while using Session EJB's. The article even provides code. Also, since you are using Prepared Statements, you even get the advantage of WebSphere's PreparedStatement cache, which doesn't cache the data, but does speed up queries.
Kyle

------------------
Kyle Brown,
Author of Enterprise Java (tm) Programming with IBM Websphere
See my homepage at http://members.aol.com/kgb1001001 for other WebSphere information.
 
Kyle Brown
author
Ranch Hand
Posts: 3892
5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Son Java:
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 far as I know in "exclusive mode" (Option A) WebSphere does not put ANY locks on the database at all. These are only used in Option C. The idea of Option A is that no other application (including other clones of the curent application server) will have access to those rows, period. Exclusive means exclusive.

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

I know that there are issues in the Isolation levels with Oracle -- basically the problem being that Oracle's isolation levels don't map well to the EJB specification. Check on the IBM web site for information on this. You might want to try dropping the Isolation level...
Kyle

------------------
Kyle Brown,
Author of Enterprise Java (tm) Programming with IBM Websphere
See my homepage at http://members.aol.com/kgb1001001 for other WebSphere information.
 
Son Java
Greenhorn
Posts: 9
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
 
Son Java
Greenhorn
Posts: 9
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
 
Son Java
Greenhorn
Posts: 9
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
 
Son Java
Greenhorn
Posts: 9
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Is OPTION A applicable for BMP in Websphere?
Thanks
Alagan
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!