Object locking of entity bean in a SSBean[Environment: WebLogic 10.0, EJB3.0, Kodo/OpenJPA]

Hello friends,
I am facing bottle neck with Object Locking for an Entity bean using OpenJPA Persistence Manager under Weblogic 10.0 application server deployments.
I want to block [ for the specific method ] entity bean being accessed from other client programs when they invoke common method in a Stateless Session EJB. Particularly, Consider the situation:
Client1: Modifying Customer entity with id: 100. Then I locked that entity using OpenJPA Entity Manager within the transaction block. And i entered that thread to sleep before committing the transaction.
At this time, started new thread, Client2: Modifying the same Customer entity with id:100. I expected this thread will be get blocked when control pass to the lock() method. But it doesn't happened. It goes through the line of codes and also put into sleep.
After thread sleep timeout, first thread Client1 commit successfully. But the second gets Rollback Exception due to optimistic lock exception occurring since customer entity is modified in another transaction.
This exception is occurred because of Database level concurrency control for optimistic locking in a weblogic server. Its default to weblogic.
But, what i expected is to assert lock at the object level, thereby the 2nd thread - Client2 will be blocked while Client1 is in the middle of a transaction and then Client2 use modified Customer entity . But it doesn't happened. I used Kodo Persistance Provider as Persistence Unit, OpenJPAEntityManager to do transaction, locking , finding and merging the entity bean.
Can anyone provide help to fine grain this object locking functionality ??? I look forward to your brilliant thoughts......
Rajesh KR
Geojit Technologies

Dear Chicon,
I made thread to sleep for checking the "Object Locking" functionality of OpenJPAEntityManager. My intention was to block the second thread when the first thread being locked when a concurrent access occurs. But it doesn't happened and code execution passed to thread sleep.
I mean when 2 client access the same entity at same time (in same milliseconds) , and what happens to 2nd thread when 1st thread locks the entity object.
I guarantee you that i started the 2nd thread before the 4sec time stamp given to the object locking. I tested it with a bigger timestamp, still it given concurrent blocking of the same entity bean.
My question is why the object locking is not working with concurrent access to same entity bean from more than one thread???
I think you get the correct question what i intended ????
Regards,
Raj...

Similar Messages

Object attribute for Entity Bean?

Can I have an Object type attribute in an Entity Bean that must be mapped to a database. This Object will then only contain text attributes. For example,
class UserBean {
String name;
Address address;
class Address {
String street;
String streetnumber;
In other words: Can I use EJB's to provide the same facility that an Object-Oriented Database provides?

Providing you are not worried about referential integrity, CMP will do this automatically.

Error in deploying entity beans - migration from JBoss to Weblogic 10.3.4

Hi,
I am migrating EJB2.x code from JBoss to Weblogic 10.3.4. As a first step, I am tyring to deploy just Entity beans. I get following error when deploying to server.
'weblogic.application.ModuleException: Exception preparing module: EJBModule(myEJB.jar)
Unable to deploy EJB: CollMetaData from myEJB.jar:
[EJB:011017]Error while reading 'META-INF/weblogic-cmp-rdbms-jar.xml'. The error was:
There are 1 nested errors:
java.lang.NullPointerException
     at weblogic.ejb.container.cmp.rdbms.finders.EjbqlFinder.setMethods(EjbqlFinder.java:288)
     at weblogic.ejb.container.cmp.rdbms.Deployer.processFinders(Deployer.java:744)
     at weblogic.ejb.container.cmp.rdbms.Deployer.readTypeSpecificData(Deployer.java:446)
     at weblogic.ejb.container.persistence.PersistenceType.setTypeSpecificFile(PersistenceType.java:506)
     at weblogic.ejb.container.persistence.PersistenceType.setupDeployer(PersistenceType.java:455)
     at weblogic.ejb.container.deployer.CMPInfoImpl.setup(CMPInfoImpl.java:118)
     at weblogic.ejb.container.deployer.EJBDeployer.prepare(EJBDeployer.java:1214)
     at weblogic.ejb.container.deployer.EJBModule.prepare(EJBModule.java:442)
     at weblogic.application.internal.flow.ModuleListenerInvoker.prepare(ModuleListenerInvoker.java:199)
     at weblogic.application.internal.flow.DeploymentCallbackFlow$1.next(DeploymentCallbackFlow.java:517)
     at weblogic.application.utils.StateMachineDriver.nextState(StateMachineDriver.java:52)
     at weblogic.application.internal.flow.DeploymentCallbackFlow.prepare(DeploymentCallbackFlow.java:159)
     at weblogic.application.internal.flow.DeploymentCallbackFlow.prepare(DeploymentCallbackFlow.java:45)
     at weblogic.application.internal.BaseDeployment$1.next(BaseDeployment.java:613)
     at weblogic.application.utils.StateMachineDriver.nextState(StateMachineDriver.java:52)
     at weblogic.application.internal.BaseDeployment.prepare(BaseDeployment.java:184)
     at weblogic.application.internal.EarDeployment.prepare(EarDeployment.java:58)
     at weblogic.application.internal.DeploymentStateChecker.prepare(DeploymentStateChecker.java:154)
     at weblogic.deploy.internal.targetserver.AppContainerInvoker.prepare(AppContainerInvoker.java:60)
     at weblogic.deploy.internal.targetserver.operations.ActivateOperation.createAndPrepareContainer(ActivateOperation.java:207)
     at weblogic.deploy.internal.targetserver.operations.ActivateOperation.doPrepare(ActivateOperation.java:98)
     at weblogic.deploy.internal.targetserver.operations.AbstractOperation.prepare(AbstractOperation.java:217)
     at weblogic.deploy.internal.targetserver.DeploymentManager.handleDeploymentPrepare(DeploymentManager.java:747)
     at weblogic.deploy.internal.targetserver.DeploymentManager.prepareDeploymentList(DeploymentManager.java:1216)
     at weblogic.deploy.internal.targetserver.DeploymentManager.handlePrepare(DeploymentManager.java:250)
     at weblogic.deploy.internal.targetserver.DeploymentServiceDispatcher.prepare(DeploymentServiceDispatcher.java:159)
     at weblogic.deploy.service.internal.targetserver.DeploymentReceiverCallbackDeliverer.doPrepareCallback(DeploymentReceiverCallbackDeliverer.java:171)
     at weblogic.deploy.service.internal.targetserver.DeploymentReceiverCallbackDeliverer.access$000(DeploymentReceiverCallbackDeliverer.java:13)
     at weblogic.deploy.service.internal.targetserver.DeploymentReceiverCallbackDeliverer$1.run(DeploymentReceiverCallbackDeliverer.java:46)
     at weblogic.work.SelfTuningWorkManagerImpl$WorkAdapterImpl.run(SelfTuningWorkManagerImpl.java:528)
     at weblogic.work.ExecuteThread.execute(ExecuteThread.java:207)
     at weblogic.work.ExecuteThread.run(ExecuteThread.java:176)
Can someone help me fixing the issue?
I changed schema locations of descriptor files as suggested at http://download.oracle.com/docs/cd/E17904_01/web.1111/e13706/overview.htm#i1074199 (see the third category for '*Enterprise Bean 2.1*' in the listing Table 1-1). Alternatively, you may see the schema locations for EJB2.0 directly at http://download.oracle.com/docs/cd/E17904_01/web.1111/e13719/dd_reference.htm#EJBPG481

JRE version in JBoss is 1.6.0_16. JVM in web logic is pointing to jrockit_160_22_D1.1.1-3 which is come in the package. It doesn't seem to be related to JVM version mismatch.
I think it is an issue with definitions in weblogic-cmp-rdbms-jar.xml file. How should be the definition of entity-descriptor appear for entity bean which has finder methods in ejb-jar.xml?
Please see the snippets from corresponding descriptor files below.
ejb-jar.xml
=========
<entity>
<display-name>EmpBean</display-name>
<ejb-name>EmpBean</ejb-name>
<local-home>LocalEmpBeanHome</local-home>
<local>LocalEmpBean</local>
<ejb-class>EmpBeanBean</ejb-class>
<persistence-type>Container</persistence-type>
<prim-key-class>java.lang.String</prim-key-class>
<reentrant>False</reentrant>
<cmp-version>2.x</cmp-version>
<abstract-schema-name>EmpBean</abstract-schema-name>
<cmp-field>
<field-name>firstName</field-name>
</cmp-field>
<cmp-field>
<field-name>lastName</field-name>
</cmp-field>
<cmp-field>
<field-name>phone</field-name>
</cmp-field>
<cmp-field>
<field-name>address</field-name>
</cmp-field>
<primkey-field>lastName</primkey-field>
<query>
<query-method>
          <method-name>findByPrimaryKey</method-name>
               <method-params>
               <method-param>java.lang.String</method-param>
               </method-params>
          </query-method>
          <ejb-ql>SELECT Object(o) FROM EmpBean o WHERE o.lastName= ?1</ejb-ql>
     </query>
</entity>
weblogic-jar.xml
============
<weblogic-enterprise-bean>
<ejb-name>EmpBean</ejb-name>
<entity-descriptor>
     <pool>
          <max-beans-in-free-pool>20</max-beans-in-free-pool>
          <initial-beans-in-free-pool>5</initial-beans-in-free-pool>
     </pool>
<persistence>
<persistence-use>
<type-identifier>WebLogic_CMP_RDBMS</type-identifier>
<type-version>6.0</type-version>
<type-storage>meta-inf/weblogic-cmp-rdbms-jar.xml</type-storage>
</persistence-use>
<finders-load-bean>true</finders-load-bean>
</persistence>
</entity-descriptor>
<local-jndi-name>ejb/EmpBean</local-jndi-name>
</weblogic-enterprise-bean>
weblogic-cmp-rdbms-jar.xml
====================
<weblogic-rdbms-bean>
<ejb-name>EmpBean</ejb-name>
<data-source-jndi-name>mysqlDS</data-source-jndi-name>
<table-map>
<table-name>emp</table-name>
<field-map>
<cmp-field>firstName</cmp-field>
<dbms-column>first_namel</dbms-column>
</field-map>
<field-map>
<cmp-field>lastName</cmp-field>
<dbms-column>last_name</dbms-column>
</field-map>
<field-map>
<cmp-field>phone</cmp-field>
<dbms-column>phone</dbms-column>
</field-map>
<field-map>
<cmp-field>address</cmp-field>
<dbms-column>address</dbms-column>
</field-map>
</table-map>
<weblogic-rdbms-bean>
Please ignore any typos that you may notice in above sample descriptions (because I just typed it here changing original names).
When I try to deploy the application, I get error message as posted in my first post above in this thread. Please correct me if I am making any erros in descriptor files.
Edited by: 839281 on Feb 25, 2011 10:55 AM
Edited by: venkatp on Mar 1, 2011 9:31 AM

Wrong version of an entity bean object being updated

We are having a problem with an entity bean that uses bean managed persistence. The "order" entity bean has
been used as part of our Order Routing System for the last 2 years with no problems. The entity bean is
accessed via calls from a "Order Manager" session bean. No change has been done to the entity bean but the
frequency of calls from the session bean to update the entity bean have increased significantly.
The "order" entity bean wraps an Order object that contains order properties (i.e. id, quantity, price,
version, etc). The entity bean has a "void setOrder(Order param)" function that writes the Order to a database
and a "Order getOrder()" function that clones and returns the internal Order object. The "ejbLoad()" function
reads the Order object from the database and the "ejbStore()" function is not implemented.
The "OrderEntityPK ejbFindByPrimaryKey()" function checks if the order entity primary key (an "int") exists
on the database.
We are using the SilverStream 3.5 application server as our EJB container. According to the SilverStream manual
it does not maintain a pool of idle/unused entity beans, instead it instantiates beans as requested.
Our problem is:
1) The wrong version of the entity object is sometimes being updated (i.e. an old instance of the order entity is being
picked up and updated on the database).
2) We sometimes get a TransactionRequired exception thrown when we have concurrent updates to two different
objects of the entity bean.
Any idea as to what our problem could be?
Thanks in advance for your help,
The following are the main code snippets:
Original Code
Session Bean A
Method 1 --- gets entity Bean B and calls a method on a different object passing this entity bean
          in as a parameter to enable a method on this bean to be called.
EntityBean lOrderEntity = findOrderEntity(callerUnixLogin, currOrderId);
               currOrder = lOrderEntity.getOrder();
               //Logic to update the currOrder object via a method call.
               persistManager.persistOrder(lOrderEntity, callerUnixLogin, currOrder, psTransactionType);
     persistManager.persistOrder Method:
               lOrderEntity.setOrder(callerUnixLogin, order);
     findOrderEntity method:
OrderEntity lOrderEntity = null;
          OrderEntityBeanPK orderPK = new OrderEntityBeanPK(orderId);
          try
               if (orderEntityHome == null)
                    connectToOrderEntityBean(callerUnixLogin);
               lOrderEntity = orderEntityHome.findByPrimaryKey(orderPK);
          ... etc
Current Code
Session Bean C
Method 2 ---- calls method 1 in Session Bean A
Calls to method 2 above happens in quick succession.
OrderEntityBean class
... important methods ...
     private Order order = null;
     public OrderEntityBeanPK ejbFindByPrimaryKey(OrderEntityBeanPK primaryKey)
          throws FinderException, RemoteException, DBOException
          try
               orderObjectManager.orderIdExists(primaryKey.orderId);
          catch (OMOrderValidationException exc)
               throw new FinderException(exc.getMessage());
          return primaryKey;
     public void setOrder(String userUnixLogin, Order newOrder)
          throws EJBException, RemoteException, DBOException, OMFormattingException, OMOrderValidationException
          callerUnixLogin = userUnixLogin;
          int version = newOrder.getOrderVersion().intValue();
          if (order.getOrderVersion().intValue() == version)
               order = null;
               order = newOrder;
               Integer newVersion = new Integer(version + 1);
               order.setOrderVersion(newVersion);
               newVersion = null;
               order.setSysUser(callerUnixLogin);
               orderObjectManager.updateOrder(callerUnixLogin, order);
          else
               Debug.Print(userUnixLogin, "OrderEntityBean.setOrder: wrong version number for order " + newOrder.getOrdId() +
                    ": expected " + order.getOrderVersion() + " and got " + newOrder.getOrderVersion(), 0);
               throw new OMOrderValidationException("wrongVersion", order, order.getOrdId(), IName.Order.VERSION, newOrder.getOrderVersion());
     public Order getOrder()
          throws EJBException, RemoteException
return ((Order)order.clone());
The following transactions exists for the entity bean ...
Required:
     create and setOrder methods
Not Supported
     findByPrimary and getOrder methods

"The entity bean has a "void setOrder(Order param)" function that writes the Order to a database"
This functionality should be performed in the ejbStore method().
"a "Order getOrder()" function that clones and returns the internal Order object."
Sounds reasonable, except for the cloning part.
"The "ejbLoad()" function reads the Order object from the database"
Cool.
""ejbStore()" function is not implemented."
Whoops. Looks like your setOrder method is doing too much. It should do the inverse of getOrder (namely, setting the interal Order object), nothing more. Defer the persistence code to the ejbStore method.
"According to the SilverStream manual it does not maintain a pool of idle/unused entity beans, instead it instantiates beans as requested."
Manual? What's that? Assuming that is correct, better hope you don't ever get a high load. You might wanna look into JBoss.
"2) We sometimes get a TransactionRequired exception thrown when we have concurrent updates to two different objects of the entity bean."
How can you have concurrent access to two different objects?? Concurrency is inherently applicable to only one object.
In summary:
Write your beans properly, ejbLoad populates the bean with data, ejbStore persists the bean's data.
Get a better (and possibly free) appserver.

CMP Entity Bean with ejb-ql finder methods and INFORMIX database

Hi,
I have some CMP Entity Beans with finder methods defined in ejb-ql. In my ejb-jar, within <entity> definitions I have something like:
    <entity>
      <abstract-schema-name>BeanName</abstract-schema-name>
      <cmp-field><field-name>fieldOne</field-name></cmp-field>
      <cmp-field><field-name>fieldTwo</field-name></cmp-field>
      <query>
        <query-method>
          <method-name>findAll</method-name>
          <method-params></method-params>
        </query-method>
        <ejb-ql>SELECT OBJECT(o) FROM BeanName o</ejb-ql>
      </query>
    <entity>
And in persistent.xml:
<db-properties>
     <data-source-name>datasource_name</data-source-name>
</db-properties>
<entity-bean>
     <ejb-name>BeanName</ejb-name>
     <table-name>table_name</table-name>
     <field-map key-type="NoKey">
     <field-name>fieldOne</field-name>
     <column><column-name>column_one</column-name></column>
      </field-map>
     <field-map key-type="NoKey">
     <field-name>fieldTwo</field-name>
     <column><column-name>column_two</column-name></column>
      </field-map>
      <finder-descriptor>
          <method-name>findAll</method-name>
          <method-params/>
     </finder-descriptor>
Once deployed, on server side, I can found a java source file (with corresponding compiled class file) in path:
j2ee/cluster/server0/apps/companyName/MyEARApp/EJBContainer/temp/temp38837373733/route/to/package/
with names:
BeanName0_0pm.java
BeanName0_0PM.class
and the generated java file contains this code:
public java.util.Enumeration ejbFindAll() throws javax.ejb.FinderException, javax.ejb.EJBException {
    TransactionContext tc = pm.getTransactionContext();
    Connection conn = null;
    PreparedStatement pSt = null;
    ResultSet ejb_rs = null;
    int status = javax.transaction.xa.XAResource.TMSUCCESS;
    try {
      conn = pm.getConnectionForFindMethod();
      pSt = conn.prepareStatement("SELECT \"O\".\"COLUMN_ONE\",\"O\".\"COLUMN_TWO\", FROM \"TABLE_NAME\" \"O\"");
      ejb_rs = pSt.executeQuery();
I'm trying to call this method but it throws a SQLException when preparing the statement.
It seems that Informix does not like this SQL syntax because of upper case names, doble quotes on table alias, or something else.
When editing persistent.xml in netweaver, I can define the element <datasource-vendor> as ORACLE, SAPDB, MS_SQL_SERVER, DB2_UDB_AS400 or DB2_UDB_OS390 but INFORMIX is not an accepted value.
Is there any way to define how this SQL query is build?
Thanks in advance.

The return type of the finder method defined in the remote home interface is either the entity bean's remote interface or a collection of objects implementing the entity bean's remote interface. The return type of the finder method defined in the local home interface is either the entity bean's local interface or a collection of objects implementing the entity bean's local interface

Finder method in container-managed entity bean

Finder method of a container entity bean is taking the primary key class object of another entity bean. How to map this in the xml descriptor file weblogic-cmp-rdbms.xml for this type of beans.
I am trying to deploy the jasmine computer store of Mastering EJB by EdRoman.
I couldn't write the deployment file weblogic-cmp-rdbms.xml for Order Entity bean which uses CustomerPK as an argument in its finder method.
Please tell me how to write this. I am trying on weblogic 5.1
Thanx in advance
Srivatsa

hello,
in container managed persistence, you specify on your xml file the name of your table. so the primary key you want to use have to be a foreign key in your table. otherwise i don't think that you can use a container managed persistence.
Najib.

Global Variable in entity beans

Dear Friends,
For example let us think that we have an entity bean for Customer.
and we created an instance of that bean for customer A and then for customer B.
So will the global variables in Customer bean be shared across Customer A and Customer B or will there be seperate instances for both Customers.
Thanking You,
Chamal.

Your concepts seem to be a little messed up.
For entity bean, remember the following:
1. each object/instance of entity bean represents a record in a database
2. when a client looks up an entity bean (typcially by using findByPrimaryKey method on home object), the record from database is searched and its values are stored in Entity Beans variables (this is probably what you mean by Global Variable. But thats an incorrect terminology in Java/J2EE. Class attribute is the correct word)
3. In step 2, you fetched a record and that record is represented by a java object, which is nothing but entity bean.
4. Now if you make changes to this java object, these changes will persist in the database. That is the essence of entity bean.
5. If you use the home object's findByPrimaryKey method and look for the same record, no new object will be created. The 2 remote objects will point to the same entity bean on the server.
6. If yo use the home object's findByPrimaryKey method and look for another record/customer, a new object will be created on the server. This new entity bean will map to the new record.
Note taht the attribtues of CustomerA and customerB will never be shared.
hope that helps

NON-transactional session bean access entity bean

We are currently profiling our product using Borland OptmizeIt tool, and we
found some interesting issues. Due to our design, we have many session beans which
are non transactional, and these session beans will access entity beans to do
the reading operations, such as getWeight, getRate, since it's read only, there
is no need to do transaction commit stuff which really takes time, this could
be seen through the profile. I know weblogic support readonly entity bean, but
it seems that it only has benefit on ejbLoad call, my test program shows that
weblogic still creates local transaction even I specified it as transaction not
supported, and Transaction.commit() will always be called in postInvoke(), from
the profile, we got that for a single method call, such as getRate(), 80% time
spent on postInvoke(), any suggestion on this? BTW, most of our entity beans are
using Exclusive lock, that's the reason that we use non-transactional session
bean to avoid dead lock problem.
Thanks

Slava,
Thanks for the link, actually I read it before, and following is what I extracted
it from the doc:
<weblogic-doc>
Do not set db-is-shared to "false" if you set the entity bean's concurrency
strategy to the "Database" option. If you do, WebLogic Server will ignore the
db-is-shared setting.
</weblogic-doc>
Thanks
"Slava Imeshev" <[email protected]> wrote:
Hi Jinsong,
You may want to read this to get more detailed explanation
on db-is-shared (cache-between-transactions for 7.0):
http://e-docs.bea.com/wls/docs61/ejb/EJB_environment.html#1127563
Let me know if you have any questions.
Regards,
Slava Imeshev
"Jinsong HU" <[email protected]> wrote in message
news:[email protected]...
Thanks.
But it's still not clear to me in db-is-shared setting, if I specifiedentity
lock as database lock, I assumed db-is-shared is useless, because foreach
new
transaction, entity bean will reload data anyway. Correct me if I amwrong.
Jinsong
"Slava Imeshev" <[email protected]> wrote:
Jinsong,
See my answers inline.
"Jinsong Hu" <[email protected]> wrote in message
news:[email protected]...
Hi Slava,
Thanks for your reply, actually, I agree with you, we need to
review
our db
schema and seperate business logic to avoid db lock. I can not say,guys,
we need
to change this and that, since it's a big application and developedsince
EJB1.0
spec, I think they are afraid to do such a big change.Total rewrite is the worst thing that can happen to an app. The
better aproach would be identifying the most critical piece and
make a surgery on it.
Following are questions in my mind:
(1) I think there should be many companies using weblogic serverto
develop
large enterprise applications, I am just wondering what's the maintransaction/lock
mechanism that is used? Transional session / database lock,
db-is-shared
entity
I can't say for the whole community, as for my experience the standard
usage patthern is session fasades calling Entity EJBs while having
Required TX attribute plus plain transacted JDBC calls for bulk
reads or inserts.
is the dominant one? It seems that if you speficy database lock,
the
db-is-shared
should be true, right?Basically it's not true. One will need db-is-shared only if thereare
changes
to the database done from outside of the app server.
(2) For RO bean, if I specify read-idle-timeout to 0, it shouldonly
load
once at the first use time, right?I assume read-timeout-seconds was meant. That's right, but if
an application constantly reads new RO data, RO beans will be
constantly dropped from cache and new ones will be loaded.
You may want to looks at server console to see if there's a lot
of passivation for RO beans.
(3) For clustering part, have anyone use it in real enterpriseapplication?
My concern, since database lock is the only way to choose, how aboutthe
affect
of ejbLoad to performance, since most transactions are short live,if high
volume
transactions are in processing, I am just scared to death about
the
ejbLoad overhead.
ejbLoad is a part of bean's lifecycle, how would you be scared ofit?
If ejbLoads take too much time, it could be a good idea to profile
used SQLs. Right index optimization can make huge difference.
Also you may want cosider using CMP beans to let weblogic
take care about load optimization.
(4) If using Optimization lock, all the ejbStore need to do
version
check
or timestamp check, right? How about this overhead?As for optimistic concurrency, it performs quite well as you can
use lighter isolation levels.
HTH,
Slava Imeshev
"Jinsong Hu" <[email protected]> wrote in message
news:[email protected]...
We are using Exclusive Lock for entity bean, because of we do
not
want
to
load
data in each new transaction. If we use Database lock, that means
we
dedicate
data access calls to database, if database deadlock happens,
it's
hard
to
detect,
while using Exclusive lock, we could detect this dead lock in
container
level.
The problem is, using Exclusive concurrency mode you serialize
access to data represented by the bean. This aproach has negative
effect on ablity of application to process concurrent requests.As
a
result the app may have performance problems under load.
Actually, at the beginnning, we did use database lock and usingtransactional
The fact that you had database deadlocking issues tells that
application logic / database schema may need some review.
Normally to avoid deadlocking it's good to group database
operations mixing in updattes and inserts into one place so
that db locking sequence is not spreaded in time. Moving to
forced serialized data access just hides design/implementation
problems.
session bean, but the database dead lock and frequent ejbLoad
really
kill
us,
so we decided to move to use Exclusive lock and to avoid dead
lock,
we
change
some session bean to non-transactional.Making session beans non-transactions makes container
creating short-living transactions for each call to entity bean
methods. It's a costly process and it puts additional load to
both container and database.
We could use ReadOnly lock for some entity beans, but since weblogicserver will
always create local transaction for entity bean, and we found
transaction
commit
is expensive, I am arguing why do we need create container leveltransaction for
read only bean.First, read-only beans still need to load data. Also, you may seeRO
beans
contanly loading data if db-is-shared set to true. Other reason
can
be
that
RO semantics is not applicable the data presented by RO bean (forinstance,
you have a reporting engine that constantly produces "RO" data,
while
application-consumer of that data retrieves only new data and neverasks
for "old" data). RO beans are good when there is a relatively stable
data
accessed repeatedly for read only access.
You may want to tell us more about your app, we may be of help.
Regards,
Slava Imeshev
I will post the performance data, let's see how costful
transaction.commit
is.
"Cameron Purdy" <[email protected]> wrote:
We are currently profiling our product using Borland
OptmizeIt
tool,
and we
found some interesting issues. Due to our design, we have
many
session
beans which
are non transactional, and these session beans will access
entity
beans
to
do
the reading operations, such as getWeight, getRate, since
it's
read
only,
there
is no need to do transaction commit stuff which really takes
time,
this
could
be seen through the profile. I know weblogic support readonly
entity
bean,
but
it seems that it only has benefit on ejbLoad call, my test
program
shows
that
weblogic still creates local transaction even I specified
it
as
transaction not
supported, and Transaction.commit() will always be called
in
postInvoke(),
from
the profile, we got that for a single method call, such as
getRate(),
80%
time
spent on postInvoke(), any suggestion on this? BTW, most of
our
entity
beans are
using Exclusive lock, that's the reason that we use
non-transactional
session
bean to avoid dead lock problem.I am worried that you have made some decisions based on an improper
understand of what WebLogic is doing.
First, you say "non transactional", but from your description
you
should
have those marked as tx REQUIRED to avoid multiple transactions
(since
non-transactional just means that the database operation becomesits
own
little transaction).
Second, you say you are using exclusive lock, which you shouldonly
use
if
you are absolutely sure that you need it, (and note that it
does
not
work in
a cluster).
Peace,
Cameron Purdy
Tangosol, Inc.
http://www.tangosol.com/coherence.jsp
Tangosol Coherence: Clustered Replicated Cache for Weblogic
"Jinsong Hu" <[email protected]> wrote in message
news:[email protected]...
>

Entity bean for shared acces without database access

Hi all,
I would like to create an entity bean to store data common for all application users. This bean does not have to have a database link, it should only keep data in memory until no user left.
Is it possible ? And if yes, how ?
I have already created a session bean that works but only keep data for one users session, and I have created an entity bean but it seems that it requires a database link.
Thanks
Sylvain

Sylvain,
I am assuming that you are using webdynpro for this.
You have a provision to use 'Dictionary' objects to handle CRUD operations in webdynpro and also at EJB level.
I can suggest you to handle this scenario in two ways.
1) If you are trying to perform the persistance at Webdynpro level, You can create the dictionary object straightaway in the webdynpro component.
2) If you are trying to perform persistance at EJB level using entity bean, I suggest you to maintain/create a dictionary object using your NWDS and access that Dictionary object at your entity bean using dictionary by packagename. Ofcourse you may have to write the CRUD operations code by urself.
I hope that this information would be most useful.

Jprobe Memory Debugger with Entity Bean

hi,
I m testing an EJB application(Bean Managed) using Jprobe Memory debugger.
While testing it gives me that objects referred by entity bean are loitering . for eg if somewhere in my code i created an integer using new Integer and if I m letting it passed to ejbCreate .then that object is pointed as loitering while debugging. further it happens with srtring and data access Objects and otheres as well.
so is there a memory Leak or The debugger is handling the entity bean in such a way.
version of jprobe used is 5.2.3 on windows
Please provide me help regarding the same

Actually, what one or the developers in my group found out is two things:
1) The clone is a shallow copy.They copy the references but not objects themselves. This has been causing problems for us.
2) It seems that you don't work on a copy and you work on the original and they keep a copy. Now, this is fine IF you don't have multiple threads working on the same Entity bean and we moved our application from Weblogic where it throws an exception if that Entity bean is in use to OC4J which is suppose to copy the bean and doesn't so you have multiple threads possibly modifying the same object.

BC4J DAOs vs. Local Entity Beans

We are beginning a brand new project and trying to evaluate the costs/benefits of using BC4J entity objects versus local entity beans for our persistence needs.
I've read the "Simplifying J2EE and EJB Development with BC4J" white paper including the "How Does EJB 2.0 Change the Picture?" section, but that seems to have been written at a time when EJB 2.0 support was a rarity.
I'd like to get some feedback from people who have had experience with both. We are basically starting this application from scratch, although we have relational tables from our legacy C++ application that will serve as the basis for the Java object model. So what would we gain/lose by using entity objects?
I must admit, I'm leaning toward using entity beans over a vendor-specific persistence framework, but if there are compelling reasons to choose entity objects (besides those mentioned in the white paper), I'd like to hear them. Please speak slowly, as I'm new to BC4J. :)
Thanks for your time.

I've read the "Simplifying J2EE and EJB Development with BC4J" white paper including the "How Does EJB 2.0 Change the Picture?" section, but that seems to have been written at a time when EJB 2.0 support was a rarity.IMO there's no change.
What Sun doesn't tell you in the specs, but is much talked about on theserverside.com and in most
anti-patterns threads, and in the up coming book J2EE Anti-Patterns; EJB Entities are basically
broke with no solution. Reason: EjbStore() can throw an exception due to DB constraint violation
after the business method returns. This drives the scenario where all business integrity is
forced up into the middle tiers (EJB and business mediator tiers). etc etc ... EJB Entities are
useful for the 5% to 1% of a business model and application that is transactional IMO.
I.E. 95%++ of most apps/web sites are read only. Why use a heavy and expensive transactional
component for reading rows from a DB to be displayed on an Inventory screen? The only reason
to do this is if you have stock in Sun and your appserver vendor or want your project to last
forever or get canceled. -- Seriously, do your home work, using Entities as your persistance
tier mediator, for the 95% of your project that's read only, and for reports which involve
joins, select criteria etc etc will be a serious problem to just code and even bigger problem
to be responsive and scalable.
Do this experiment: implement a report that joins several tables, selects on where criteria,
orders by some attribute in EJB Entity bean technology. Seriously try to code this solution.
Hint: spray water on your appserver box since it'll almost explode. :)
Then try: do the same report in SQL. One SQL statement usually will do it and it's all in the
DB. The data returned to the middle tier is ready for JSP formating.
Try another EJB experiment: implement a finder based on criteria that returns a Collection.
Do the same in SQL: time the perf difference.
Hint: Maybe you're getting the picture, that EJB Entity 2.0 --> 10.0 what-ever, never wrote into
the specs any means for joins, or high perf finders based on criteria.
My opinion and experience: EJB Entity is good for one portion of a project if that; the single
part that's transactional (usually the shopping cart or similar). All other data access needs
to be through a DAO tier that's SQL based. With BC4J you get transactional support too, so
why bother with EJB, except to be wrapped by SLSB's for remotability from the client.
I'd like to get some feedback from people who have had experience with both. We are basically starting this application from scratch, although we have relational tables from our legacy C++ application that will serve as the basis for the Java object model. So what would we gain/lose by using entity objects? I'm at the end of phase one of a medium scale BC4J project which was initiated after scrapping
a Sun Blueprint J2EE 1.2 architecture for the above reasons, plus the unmentioned time to market
issue. We found hand coding the Sun architecture to be 400% slower, if you don't hit any of the
above mentioned bumps in the road. We never got to reports, which would have been imposible without
custom DAOs.
I must admit, I'm leaning toward using entity beans over a vendor-specific persistence framework, but if there are compelling reasons to choose entity objects (besides those mentioned in the white paper), I'd like to hear them. Please speak slowly, as I'm new to BC4J. :)You're not the first to ask this question nor the last. Sun's happy talk in the face of their
king has great cloths sell job to fend off .net will take more than just J2EE Anti-patterns books
to displell. Try the reports and finders experiements in EJB 2.0. You'll no doubt learn alot
and read more news group posts in the process.
Heck, you might even discover that 903 oc4j's CMR and EQL can instantiate 1000's of Entity beans,
JNDI entries, return a Collection of handles, your client get the ValueObjects and build a report
in less than a minute and 100's of customers can do this simultanteously. __NOT__ :)
Cheers,
curt

How to disable cache implementation in 8.1 SP6 for entity beans

How to disable cache implementation in 8.1 SP6 for entity beans
In our production environment, we want to disable cache implementation for entity beans. We are using weblogic 8.1 SP6.
Weblogic cache implementation has been causing many cachefull exceptions so we want that it fetches the data from database everytime instead of cache.

Check the "max-beans-in-cache" setting in your weblogic-ejb-jar.xml. The cache full exception, means that a new bean could not be created because of this cache being full.
Nothing to do with fetching from the database directly.
If you really want direct fetches then do not use beans at all. Consider using direct JDCB/SQL calls (without a entity bean) to fetch huge data.
Let's again review your application based on the below explanation before making a decision on which configuration change to perform:
If you truly have many ejbs simultaneously enrolled in transactions, then yes, the cache must be big enough to hold all the instances.
Your cache must have a max size large enough to handle your peak simultaneous transaction load.
Also, try to ask the following query to your application developer. Does every user actually have to have more than one bean in the cache ? Are many of these values read-only reference values that are not updated ?
SOLUTION CHOICE:
1. If you are testing with more number of users simultaneously, then you will need to increase the "max-beans-in-cache" setting in your weblogic-ejb-jar.xml to match the load.
2. If you have few users but still seeing a lot of beans, then consult with your application developer and try to ask the above questions (Does every user have more than......) and based on that try to redesign/tune your application to make it an effective Entity bean model.
3. If you have queries where huge result sets are returned, consider using plain/direct JDB/SQL calls.
Arun

Proxy object and entity Bean interaction

Hello,
I'd like to have some precisions on the interactions between the proxy object (client) and the entity bean(server):
- does J2EE provides ways for a bean to manage clients, to define roles and permissions, lock, etc ... ? What informations an entity bean can know about the clients ?.
- how does the context mechanism work on the entity bean side ?
- how does an entity bean identify different clients ? how does it recognize one from another ? I mean if client c1 and client c2 use same entity bean B, how B can manage different roles for c1 and c2, and how can B returns specific values to a particular client.
Thx.

If you can read some tutorial, you will get all the information.
I'll suggest a book EJB by richard manson publicvations oreilly.
The activities you are talking about is responsibility of container and user developed bean are totally absytracted from this system level activities.
Primary service include security which take care of activities like Authentication, access control and secure communication.
for role based access control u have container providing the identity by Principal object. DDescriptors declare which logical roles are allowed to access even perticular method of the bean.

Locking Bol entity in Simple object

Hi,
I have created a Simple Object with a structure and have assigned the BOL entity to my custom view. Now if I want to lock the structure in event handing method, the locking fails. how can I lock the custom structure?
Thanks,
Nandini

Dear Chicon,
I made thread to sleep for checking the "Object Locking" functionality of OpenJPAEntityManager. My intention was to block the second thread when the first thread being locked when a concurrent access occurs. But it doesn't happened and code execution passed to thread sleep.
I mean when 2 client access the same entity at same time (in same milliseconds) , and what happens to 2nd thread when 1st thread locks the entity object.
I guarantee you that i started the 2nd thread before the 4sec time stamp given to the object locking. I tested it with a bigger timestamp, still it given concurrent blocking of the same entity bean.
My question is why the object locking is not working with concurrent access to same entity bean from more than one thread???
I think you get the correct question what i intended ????
Regards,
Raj...

Type of Serialized Object for Entity Bean

Hi,
I develop a container managed persistence entity bean. I want to persist an object that is serializable into a database column. My database column type is a Blob. I wonder what is the type of a field in my entity bean? Please help. Thanks in advance.
Cheers,
Paul Ngo

Providing you are not worried about referential integrity, CMP will do this automatically.

Object locking of entity bean in a SSBean[Environment: WebLogic 10.0, EJB3.0, Kodo/OpenJPA]

Similar Messages

Maybe you are looking for