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?
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?
I think, therefore I exist -- Rene Descartes
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?
I think, therefore I exist -- Rene Descartes
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?.
I think, therefore I exist -- Rene Descartes
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.
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.
I think, therefore I exist -- Rene Descartes
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.
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 think, therefore I exist -- Rene Descartes
As per the above discussion, each request should go to database and shouldn't use cache with "Database" concurrecy, right?
I think, therefore I exist -- Rene Descartes
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?
SCJP 1.4, SCWCD 1.3, SCBCD 1.3
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.
Finally I would recommend you to focus on testing the optimistic concurrency strategy, because it might be a big help for your requirements.
Is it a requirement that this data must have been committed?
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.
I think, therefore I exist -- Rene Descartes
Finally the container checks if the client copy and the real data are the same in order to update the database.
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.
I think, therefore I exist -- Rene Descartes
I think, therefore I exist -- Rene Descartes
I think, therefore I exist -- Rene Descartes
I think, therefore I exist -- Rene Descartes
Don't get me started about those stupid light bulbs. |