We have weblogic5.1 SP8, and have BMP Entity Beans deployed on a 2-machine cluster. The EJB's are further optimized - in code, so that they only read from the db if there is a change (all changes are tracked using an _is_modified boolean). I am seeing some strange behavior, and I was wondering if someone could shed some light on it:
If a request to one of the weblogic servers modifies the contents of an EJB, is the instance of the EJB on the other server automatically synchronized with it (if so, anyone know how long this takes, and if there is a way to control this time)? If it isn't automatically synchronized, then the EJB's would get out-of-sync...and would explain the behavior I am seeing. Of course, I could remove the optimization and have the ejbLoad take care of things, but that is not a very good option for this EJB - which needs to read from a lot of tables. I could also implement a database-flag/timestamp solution, but again - want to avoid the round-trip to the db is at all possible.
I think the mechanism by weblogic synchronizes entity beans across a cluster is by re-loading the entity bean. i.e., calling ejbLoad again. So, if your bean checks its local state and decides to skip ejbLoad, it will go out of sync with changes made in a peer bean in the cluster.
Also, there is nothing preventing multiple bean instances being loaded for the same entity (ie. the same primary key), even within a single ejb container.
I thought there was another mechanism, other than ejbLoad() that weblogic has to synchronize the instances of its beans...but I may be wrong on this one.
AS far as i remember , clustering in weblogic for entity beans are generally pinned , meaning request always goes to teh same server which initilated as entity beans are very heave weight components.
so if this is the case then you need to check if any other process updates teh DB apart from the enity bean you are referring.
Plz correct em if i am wrong..