Delete cached data and load from database

[sudheshna Iyer]

We are using bea weblogic 8.1sp3. In the version 1, We have developed our application using CMT, CMP entity beans.

We have used the following in weblogic-ejb-jar.xml, since the data was static and no updates to database were expected.

<max-beans-in-cache>xxxx</max-beans-in-cache>
<read-timeout-seconds>xxxxx</read-timeout-seconds>
<concurrency-strategy>ReadOnly</concurrency-strategy>

In the version2, the data in the database will be updated by the external system. So my basic question is
1. If you use the cache, how will the cache be updated with the latest data from the database?

Will the "read-timeout-seconds" gaurantee me that after those xxxxx many seconds, cahced data will be updated from the database?

or

Is there any other param that guarantee's me that after certain number of seconds all the cached data is deleted and gets
updated from the database?

I know that there are lots of documents on this topic, but Can I get the simple answer for the above question?

Thank you.

[sudheshna Iyer]

Repost please. Let me be more clear:

Having the CM entity beans refering to DB.
DB that these beans refer, will be getting updated by external process.

How do I make sure that my beans always get the latest data from the database with best response time during the peak
load to the site?

I am accessing these entity beans using home interface at only one place --> so I might not need programatically flusing the cache


Currently I am using the following in weblogic-ejb-jar.xml and it is working:
<entity-cache>
<max-beans-in-cache>100</max-beans-in-cache>
<read-timeout-seconds>86400</read-timeout-seconds>
<concurrency-strategy>Database</concurrency-strategy>
</entity-cache>
But I want to make sure the above approach is correct or
Is there any other way to improve the performance of response time + getting latest data?

[Valentin Tanase]

1. If you use the cache, how will the cache be updated with the latest data from the database?

Will the "read-timeout-seconds" gaurantee me that after those xxxxx many seconds, cahced data will be updated from the database?

Yes it does.

Is there any other param that guarantee's me that after certain number of seconds all the cached data is deleted and gets
updated from the database?

The other way that I�m aware and helps you to refresh the cache is a programmatically one. Clients could be enabled to invalidate the entire cache or only a subset of the cache; either way this will enforce a refresh on the cache.

I know that there are lots of documents on this topic, but Can I get the simple answer for the above question?

Since your question is a specific weblogic question you should probably trust the documentation more than anything else. Besides weblogic documentation is really good and trustworthy.
Regards.

[Karthik Guru]

Ok a quick question,If you are using read-only beans with Database concurrency strategy, will the cache be used at all?, wont the finder calls go to the database instead of a cache everytime you invoke it?.

[Valentin Tanase]

Hi,

Currently I am using the following in weblogic-ejb-jar.xml and it is working:
<entity-cache>
<max-beans-in-cache>100</max-beans-in-cache>
<read-timeout-seconds>86400</read-timeout-seconds>
<concurrency-strategy>Database</concurrency-strategy>
</entity-cache>
But I want to make sure the above approach is correct or
Is there any other way to improve the performance of response time + getting latest data?

With this setting you�ll basically rely on the underlying database to handle the data concurrency. Although this will always work and will help your clients getting the latest data it suffers from a huge drawback: there is no caching involved; in a way the opposite of your previous read-only strategy. There is however something in between. If your data is not changing very often than you might consider implementing the optimistic concurrency strategy. This has the advantage that data could be cached between transactions and will give you a better response time.
Regards.

[Valentin Tanase]

Hi Karthik,

Ok a quick question,If you are using read-only beans with Database concurrency strategy, will the cache be used at all?, wont the finder calls go to the database instead of a cache everytime you invoke it?.

They are basically exclusive not complementary techniques. You either use one or the other but not both. There is however a read mostly design patter that weblogic used to promote before weblogic 7.0. Basically you deploy every bean twice (with different jndi names), once for reading only purposes and second for writing purposes. Although the patern could be still used very successfully, it could be replaced in most of the cases by the optimistic concurrency strategy.
Regards.

[Karthik Guru]

Originally posted by Valentin Tanase:
Hi,
If your data is not changing very often than you might consider implementing the optimistic concurrency strategy. This has the advantage that data could be cached between transactions and will give you a better response time.
Regards.

Hi Valentin,

Does weblogic allow programmatic invalidation of cache with this setting?
I mean i have a feeling that the updates to the database by another process will not be visible to the cache and hence the application.

[Valentin Tanase]

Hi Karthik,

Does weblogic allow programmatic invalidation of cache with this setting?
I mean i have a feeling that the updates to the database by another process will not be visible to the cache and hence the application.

No this is actually little bit different. The container will cache the beans behind the scene and clients are not allowed to invalidate or refresh the cache. However when doing database updates the container will initiate an optimistic approach: it will consider that the data was not changed and will try to commit the transaction. In order to do that the container will first check if the data was not already changed, by comparing either some specifiec bean�s fields or all of them with the current values in the database. It will basically issue an UPDATE WHERE sql statement. If this fails to update the database, the container will assume that some other client modify the data and will throw an exception. Otherwise the container will commit the transaction.
Regards.

[sudheshna Iyer]

Valentin,

With the approach that I have taken, I myself don't understand what exactly is the use of "<read-timeout-seconds>86400</read-timeout-seconds>" in the following:

<entity-cache>
<max-beans-in-cache>100</max-beans-in-cache>
<read-timeout-seconds>86400</read-timeout-seconds> --> how is this useful? Can this line be removed?
<concurrency-strategy>Database</concurrency-strategy>
</entity-cache>

Are you suggesting me to use:
<concurrency-strategy>Optimistic</concurrency-strategy> --> If I use this, is it guaranteed that I get the latest
data from the database?

Also I found a note in http://e-docs.bea.com/wls/docs81/ejb/entity.html that
The EJB container does not validate Blob or Clob fields in a bean with Optimistic concurrency. The workaround is to use version or timestamp checking.

That means, I need to use: <verify-columns>Read</verify-columns> -->Will this give me any better response than using
<concurrency-strategy>Database</concurrency-strategy> approach

My requirements are as follows:

Having the CM entity beans refering to DB.
DB that these beans refer, will be getting updated by external process.

How do I make sure that my beans always get the latest data from the database with best response time during the peak
load to the site?

I am accessing these entity beans using home interface at only one place --> so I might not need programatically flusing the cache

[Karthik Guru]

Hi Sudeshna,

Originally posted by sudheshna Iyer:

With the approach that I have taken, I myself don't understand what exactly is the use of "<read-timeout-seconds>86400</read-timeout-seconds>" in the following:

<entity-cache>
<max-beans-in-cache>100</max-beans-in-cache>
<read-timeout-seconds>86400</read-timeout-seconds> --> how is this useful? Can this line be removed?
<concurrency-strategy>Database</concurrency-strategy>
</entity-cache>


There is a concurrency strategy called 'ReadOnly' that needs to be used with read only beans. Database concurrency strategy will not use the cache. So you dont need a timeout because you will always fetch the data from the DB. So if you want caching effect , it will not serve the purpose but will definitely get you the current state of the database.



Are you suggesting me to use:
<concurrency-strategy>Optimistic</concurrency-strategy> -->
If I use this, is it guaranteed that I get the latest
data from the database?


No you wont. You might instead run into OptimisticConcurrencyExcpetion on access because the data in the cache would beome stale compared to the data in the DB. You might have to catch that exception and re-try again.

[Valentin Tanase]

Hi Sudeshna,

I know it sounds little bit confusing but both read-only and optimistic concurrency strategies have the same thing in common: they provide better caching capabilities. They are actually both vendor specific solutions in order to improve the basic load-and-store cycle used to read and write entity beans (which provides no caching at all). However they are different though and the first one is more a pure caching solution than a concurrency solution. As you know the problem with the cache is always the stale data: the data in the cache and its representation in the database can go out of sync. In order to overcome this weblogic uses either a pooling approach and the container will refresh the cache after a specified amount of time (using the read-timeout-seconds deployment descriptor element), or a pooling one that allows clients to programmatically invalidate the cache and to force refreshing. Hence by specifying an adequate value for the read-timeout-seconds parameter you�ll make sure that the clients could get the latest data if they hit the server �not very often� allowing the cache to be refreshed. Of course there are obvious limitations with this approach and one can imagine situations where it might not work.
Now getting back to your requirements, you�re asking:

How do I make sure that my beans always get the latest data from the database with best response time during the peak
load to the site?

I bolded that part of your question to emphasize one thing: usually when you think about getting the data either for reading or updating, you should consider actually getting the data within a transaction. The container was designed this way and it will always cache the data with respect to client transactions. Hence stop concerning about what/when/how your bean will get the data and focus about designing straight transactions that can either retrieve or update the latest data. In this regard you should understand that a transaction which does an update will always work with optimistic concurrency, because it will either update the latest data or will throw an exception (that the client can handle) otherwise. In your case because you have external processing updating the database, I don�t think there is any way to force your beans to refresh as the data changes. As I said you should focus on designing reliable transactions. In a classic view-update scenario, when the clients first review the data and after that they updates it, you can imagine designing your transactions as follows:

Tx1: use read-only strategy for reading the data from database.

Tx2: use an optimistic strategy to update the database (see the read-mostly pattern from weblogic)

If Tx2 fails then programmatically refresh the cache (not entire cache though but only the specific data for this client � this is cluster aware consuming operation!) and redisplay it for being reviewed by the same client.

OR a more simplistic approach:

Tx1: use the database concurrency strategy (default) for reading the latest data from the database.

Tx2: use an optimistic strategy to update the database.

If Tx2 fails then redisplay the data for being reviewed by the same client.

[/list]
Yes it could be annoying and frustrating for users to spending time reviewing the data and finally not being able to update it. However you still can tune the cache and enforce optimal refreshing time. You might instruct your clients not to use the application during the load pick if possible. You can also analyze the data and come up with efficient algorithms to ignore some changes if they are not relevant, etc. Again this is not a perfect solution but it could be acceptable considering the nature of your requirements.
Regards.

[sudheshna Iyer]

Thank you karthik and Valentin. We are running load test with 75 concurrent users. I am using:
<entity-cache>
<max-beans-in-cache>100</max-beans-in-cache> --> does this line make any sense here at all?
<concurrency-strategy>Database</concurrency-strategy>
</entity-cache>

I have removed --><read-timeout-seconds>

I am getting the following error:

####<Jul 26, 2005 3:51:35 PM EDT> <Info> <EJB> <gibson> <portal> <ExecuteThread: '20' for queue: 'weblogic.kernel.Default'> <<anonymous>> <BEA1-43F1A8392D1A8843C6EB> <BEA-010033> <Exception from ejbLoad: weblogic.ejb20.cache.CacheFullException: size=3036, target=100, incr=1
weblogic.ejb20.cache.CacheFullException: size=3036, target=100, incr=1
at weblogic.ejb20.cache.EntityCache$SizeTracker.shrinkNext(EntityCache.java:438)

As per the above discussion, each request should go to database and shouldn't use cache with "Database" concurrecy, right?
Then why am I getting "CacheFullException"? I thought that <max-beans-in-cache> is of no use with "database" concurrency.

Now I have increased the cache size to 200. Does <max-beans-in-cache> mean -->number of beans that weblogic app server
can fetch into memory to serve the request at a particluar time?

[Valentin Tanase]

Hi Sudeshna,

As per the above discussion, each request should go to database and shouldn't use cache with "Database" concurrecy, right?

Exactly. However the way weblogic manages entity ejbs is a little bit more complex way than what J2EE specs mandates. Weblogic maintains a pool of bean instances as well as a cache of entity ejbs (using an LRU algorithm). Hence beans that are READY to serve client requests are always moved in to the cache. Moreover beans that are currently enlisted in a transaction are in an ACTIVE state and are also cached. Obviously in order to start a new transaction the container tries to activate the required bean. If the cache is full, weblogic will try to passivate some of the READY beans. If the cache is full and all beans are in the ACTIVE state (enlisted in other transactions) an exception will be thrown.
On the other hand, when using database concurrency strategy it is not unusual to have multiple beans with the same primary key in the cache (if two different users update the same bean concurrently then that�s what will happen � this of course because the concurrency logic is handled by the database). By setting the max-beans-in-cache = 100 you would expect to have at most 200 beans in your cache (which all can map to the same data record!), but only at most 100 of them could be either ACTIVE or READY. It�s a long story I agree but it doesn�t have anything to do with any caching strategy, it�s just how weblogic works. I wouldn�t mess with that parameter though and as far as I know it works pretty well if it is not set. If you really need to control the size of the cache, then you better try to set a higher value.
Finally I would recommend you to focus on testing the optimistic concurrency strategy, because it might be a big help for your requirements.
Regards.

[Roger Chung-Wee]

How do I make sure that my beans always get the latest data from the database with best response time during the peak load to the site?

Is it a requirement that this data must have been committed?

[sudheshna Iyer]

Karthik Guru's quote:

Are you suggesting me to use:
<concurrency-strategy>Optimistic</concurrency-strategy> -->
If I use this, is it guaranteed that I get the latest
data from the database?

No you wont. You might instead run into OptimisticConcurrencyExcpetion on access because the data in the cache would beome stale compared to the data in the DB. You might have to catch that exception and re-try again.

Valentin Tanase's quote:

Finally I would recommend you to focus on testing the optimistic concurrency strategy, because it might be a big help for your requirements.

As per the Karthik's quote, if the data is updated by the other application frequently, then won't the response time be
more than Database concurrency if I have to catch OptimisticConcurrencyExcpetion and try again? If that is the
case then what is the use of optimistic concurrency strategy?



In my application, entity beans just only read the data from the database and display to portal.
The data that is read by the entity beans will be updated by another web application.


Roger Chung-Wee 's quote:

Is it a requirement that this data must have been committed?

Yes, the data will be updated and commited by the other application.

[Valentin Tanase]

Hi

As per the Karthik's quote, if the data is updated by the other application frequently, then won't the response time be
more than Database concurrency if I have to catch OptimisticConcurrencyExcpetion and try again? If that is the
case then what is the use of optimistic concurrency strategy?

I whish I could find an easy way to explain what the optimistic concurrency strategy is. In a nutshell the optimistic concurrency strategy takes the advantage of the fact that most access to bean data is for reading purposes. Hence each client thread is given a copy of the entity bean in a very similar way the classic client-server approach works. Finally the container checks if the client copy and the real data are the same in order to update the database. The big advantage of this approach is that the container doesn�t have to follow the classic load-and-store cycle, calling the ejbStore/ejbLoad for each and every transaction. This is important to notice because it could be an overkill for many applications.

In my application, entity beans just only read the data from the database and display to portal.
The data that is read by the entity beans will be updated by another web application.

I guess that the problem that you actually try to solve is to be able to display in real time the data changes within your portal. You have to understand that this is not so obvious from your posting; or at least it wasn�t for me. If that�s correct then you wrestle with a different type of beast here. You can either try to refresh your portal periodically, in order to pool the latest data from the database (there is a specific http meta tag for this). The other option to refresh the data in real time is not going to be easy to implement. As far as I know there is no easy way of doing this. What you can try though, is to provide a java applet that uses straight RMI-IIOP to connect to your beans. You can take advantage of the RMI distributed notification model, but this is not going to be done without a fairly good amount of work. It will also work for intranet applications only, since RMI-IIOP is not easily and broadly supported by firewalls.
Regards.

[sudheshna Iyer]

Valentin,

Finally the container checks if the client copy and the real data are the same in order to update the database.

The entity beans in my application does not update the database at all. Then how will be the cache be updated?

[Valentin Tanase]

Can you please confirm whether or not the below assumption is correct:

I guess that the problem that you actually try to solve is to be able to display in real time the data changes within your portal. You have to understand that this is not so obvious from your posting; or at least it wasn�t for me. If that�s correct then you wrestle with a different type of beast here.

Regards.

[sudheshna Iyer]

Yes, it is correct.

[Valentin Tanase]

So far it was more difficult to extract the right question than to provide the right answer :-)
This kind of question is coming up pretty often on this forum and so far I didn�t see any simple answer to this problem. Maybe other people would be able to provide you a better solution, but the only one I can think of is to build straight RMI clients (see my previous posting).
Regards.

[sudheshna Iyer]

Thank you very much for all of your replies.

[Valentin Tanase]

You're very welcome, I wish I could do more to help you. Please let us know if you find any optimal solution to your problem.
Regards.

[sudheshna Iyer]

Team,

I have deployed the application with
<entity-cache>
<max-beans-in-cache>200</max-beans-in-cache>
<concurrency-strategy>Database</concurrency-strategy>
</entity-cache>

Here is the story:
Weblogic 8.1sp3 -->CMP entity beans
When I load tested the application with 50 users for 1hr with <max-beans-in-cache>100 --> application ran successfully
When I increased the load to 75 users with 2hrs --> gave me cachefullException. so increased cache size to 200--> ran
successfully.

Hence deployed the application to production. There are some other application also running on that machine.
Now we are facing OutOfMemory problem.

There is no proof from the logs that this OutOfMemoryException is caused by the application that I deployed.

We have increased the java memheap size to 100 more MB and running the application.

What are the various things that we can do to solve this problem or What will cause this problem?

I am thinking of revering <max-beans-in-cache> back to 100 if this problem occurs again.

Any good suggestions?

[Valentin Tanase]

Hi,

First you have to specify whether you�re using SUN JDK or Weblogic JRockit (which I suppose you�re using). Secondly you need to tell us the total physical memory, the size of the nursery area, the type of garbage collection algorithm, etc. you can gather all these information very easy, simply starting the wl console; click on the Servers/myserver tab, then chose the Monitoring tab. Click the JRockit sub-tab and you can see there all the settings. Finally you�d probably like to profile the server�s jvm and you might use any third party profiling tool. However if you�re using JRockit then you can start the JRockit Management Console;

see http://e-docs.bea.com/wljrockit/docs81/userguide/mancons.html

Regards