Want to protect your cyber security and still get fast solutions? Ask a secure question today.Go Premium

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 316
  • Last Modified:

How can I refresh the entitybean?

Hi friends,

  In one entitybean, there is a private method refresh(AgentPK pk), here
we load the bean instance with data from back store. This method is called
in ejbLoad(). In refresh method, we first check isModified() for the flag,
if it is true, we do the refresh, if false we do not refresh. At the end of
refresh method, however, the modification flay was set to false :
setModified(false) so that this bean will not be refreshed as long as the
server is up.

  The code is like this:

    public void ejbLoad() throws RemoteException
  {
    logDebug("ejbLoad: " + context,100);
    try {
      // call the refresh method with the current primary key.
      refresh ((AgentPK) context.getPrimaryKey ());
    }
    catch ( FinderException fe ) {
      throw new RemoteException (fe.getMessage ());
    }
  }

  private void refresh(AgentPK p_pk) throws FinderException, RemoteException
  {

    // If the EJB has not been modified, don't refresh it & short circuit!
    if ( !isModified () ) {

      logDebug("refresh: short circuited reloading of entity.",100);
      return;
    }
   ..........//do database connection and query ...//

  //set this instance not to be refreshed again
  setModified(false);
}

   Now in my client side,  we want to refresh the bean - loading most recent
data from database so that on the gui we will see the most recent data.
However, I cannot just change setModified(false) to true at the end of the
refresh method because that way I always get unnessary refreshes. My
difficulty is I cannot use setModified() directly in my client code because
I have only the pk or remote interface.
How and where would be appropriate for me to set the modification flag to
true?

  Thank you in advance for your help.

James
0
sihu
Asked:
sihu
1 Solution
 
jpk041897Commented:
One way you could solve this would be to define a service class and interface for your bean in a manner similar to the one described in the artcle:

Universal Wrapper for Entity Beans by Andrei Povodyrev and Alan Askew.
Java Developers Journal June, 2001.

The article describes a parent class and interface that allows you more flexibility in the definition of you beans than the dafault specs allow for.

With the added flexibility, you could change the modify class in a service class method and have it delegate to refresh.

0
 
jpk041897Commented:
By the way, you can read the article by downloading the electronic copy of the magazine issue at:

http://www.sys-con.com/java/
0
 
Jim CakalicSenior Developer/ArchitectCommented:
Hi, James.

My instinctive reaction is to say it sounds like you have a design/implementation defect. Either the bean values _can_ change at any time, in which case you have a high probability of defective behavior because of the caching implementation, or they _can't_ change in which case you don't really have a problem.

Really, bean value caching is a responsibility that you should leave to the container. The EJB specification defines three kinds of Entity EJB caching that can occur. Option A caching allows the container to assume that it "owns" the database. Changes will not occur except through the EJB instances of a single container. As such, the container can read the EJB state once and then hold it between transactions. Option C caching is exactly the opposite -- EJB state must be refreshed at the beginning of each transaction and flushed at the end of a transaction. Option B is a somewhat confusing "middle-ground". Depending on your container, it may support some or all of these options.

So -- 1) determine whether the bean values can change and 2) determine the commit level caching option of your container. If your bean values can change external to the EJB container then the current caching mechanism is likely a defective optimization that should be removed. If bean values cannot change except through the entity EJB, you have only one container instance in your deployment environment, and your container supports Option A caching, then remove the "custom" caching in favor of container-managed cache. Either way you don't want clients to be forced to know when they must refresh bean values.

For reference, the EJB specs which describe the commit options are available here:
    http://java.sun.com/products/ejb/docs.html

Best regards,
Jim Cakalic
0
Industry Leaders: We Want Your Opinion!

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

 
sihuAuthor Commented:
Thank you jpk and Jim,

   Jpk, I can have a simpler option to set a refresh flag when I load my hierarchy in the cache. The problem now is after I have updated the bean data on serverside, my client side(gui) still gets the old data. I wonder there must be two sets of data in the cache and even though I log out and relogin as a new user, I still cannot get the latest data that have been updated on the server side.

  Are they cached to different places?

  James
0
 
jpk041897Commented:
What application server are you using?

When you log out the entity been shoud be returned to the object pool, when you reaquire it, after an ejbActivate() call, ejbLoad() is called inmediatley.

This leads to three possibilities I can think of:

1.- Your code to modify the value of your flag is not working.

2.- Yur application server uses some form of environment property to handle entity bean persistance and you are not setting it correctly

2.- Your app server cashes the DB calls (example Oracle IAS9i) and you have incorectly set the app servers cahe configuration.

Of these three, option 1 and 2 seems the most likely.

0
 
sihuAuthor Commented:

 I looked into my code again. My gui side getting data via a Proxy which implements the remote interface of my bean. In this proxy class, there is a updateCache(EJBChangeEvent _event) method, which is supposed to update the cache when bean changes. But I did not see wherever this method is called. Actually I guess the cache was not updated at all. This may be hard for you guys to figure out without looking into the code. Any of you have experience using a proxy class to update cache?
0
 
sihuAuthor Commented:
Hi jpk, to answer your question, I am using weblogic 5.1.
The flay problems I have solved. I guess my problem now is to figure out why the proxy is not working in updating cache.
0
 
sihuAuthor Commented:
Hi Jim and JPK,

  Thank you for your responses. After reading your comments and reading weblogic documents, I did not see I should do anything with my deployment xmls. Here I'd like to post them to you so that you may give me better directions. Thank you.
*********** **
* ejb-jar.xml
**************

<?xml version="1.0"?>

<!DOCTYPE ejb-jar PUBLIC '-//Sun Microsystems, Inc.//DTD Enterprise JavaBeans 1.1//EN' 'http://java.sun.com/j2ee/dtds/ejb-jar_1_1.dtd'>

<ejb-jar>
   <enterprise-beans>
     <entity>
    <ejb-name>com.app.cajims.ejb.entitybean.AgentHome</ejb-name>
    <home>com.app.cajims.ejb.entitybean.agent.AgentHome</home>
    <remote>com.app.cajims.ejb.entitybean.agent.AgentEJB</remote>
    <ejb-class>com.app.cajims.ejb.entitybean.agent.AgentBean</ejb-class>
    <persistence-type>Bean</persistence-type>
    <prim-key-class>com.app.cajims.ejb.entitybean.agent.AgentPK</prim-key-class>
    <reentrant>True</reentrant>
     </entity>
   </enterprise-beans>
   <assembly-descriptor>
     <container-transaction>
    <method>
      <ejb-name>com.app.cajims.ejb.entitybean.AgentHome</ejb-name>
      <method-intf>Remote</method-intf>
      <method-name>*</method-name>
    </method>
    <trans-attribute>Required</trans-attribute>
     </container-transaction>
   </assembly-descriptor>
 </ejb-jar>

***********************
*weblogic-ejb-jar.xml
**********************
<?xml version="1.0"?>

<!DOCTYPE weblogic-ejb-jar PUBLIC '-//BEA Systems, Inc.//DTD WebLogic 5.1.0 EJB//EN' 'http://www.bea.com/servers/wls510/dtd/weblogic-ejb-jar.dtd'>

<weblogic-ejb-jar>
   <weblogic-enterprise-bean>
     <ejb-name>com.app.cajims.ejb.entitybean.AgentHome</ejb-name>
     <caching-descriptor>
    <max-beans-in-free-pool>100</max-beans-in-free-pool>
    <max-beans-in-cache>3000</max-beans-in-cache>
    <idle-timeout-seconds>3600</idle-timeout-seconds>
     </caching-descriptor>
     <persistence-descriptor>
    <delay-updates-until-end-of-tx>false</delay-updates-until-end-of-tx>
     </persistence-descriptor>
     <jndi-name>com.app.cajims.ejb.entitybean.AgentHome</jndi-name>
     <transaction-isolation>
    <isolation-level>TRANSACTION_READ_COMMITTED</isolation-level>
    <method>
      <ejb-name>com.app.cajims.ejb.entitybean.AgentHome</ejb-name>
      <method-intf>Remote</method-intf>
      <method-name>*</method-name>
    </method>
     </transaction-isolation>
   </weblogic-enterprise-bean>
 </weblogic-ejb-jar>
0
 
sudhakar_koundinyaCommented:
No comment has been added lately, so it's time to clean up this TA.
I will leave a recommendation in the Cleanup topic area that this question is:


[paq'ed/points refunded]


Please leave any comments here within the next seven days.
 
PLEASE DO NOT ACCEPT THIS COMMENT AS AN ANSWER!
 
sudhakar_koundinya
EE Cleanup Volunteer
---------------------
If you feel that your question was not properly addressed, or that none of the comments received were appropriate answers, please post your concern in THIS thread.
0
 
YensidModCommented:
Question is PAQ'd and points refunded.

YensidMod
Community Support Moderator @Experts Exchange
0

Featured Post

Free Tool: Port Scanner

Check which ports are open to the outside world. Helps make sure that your firewall rules are working as intended.

One of a set of tools we are providing to everyone as a way of saying thank you for being a part of the community.

Tackle projects and never again get stuck behind a technical roadblock.
Join Now