Transaction on Entity Bean

Hi, I use the version 9.0.4.0.0
If I give an entity bean transaction type supports... what will be the actual transaction type when the bean is deployed....
So far I know the container does not suppert the tranaction type supports...
From
Oracle® Application Server Containers for J2EE
Enterprise JavaBeans Developer’s Guide
10g (9.0.4)
All entity beans with CMP and CMR relationships must be involved in a
transaction. As such, you cannot define any entity bean with a transaction attribute
of NEVER, SUPPORTS, or NOT_REQUIRED as this would put the entity outside of
a transaction.
But I can still deploy an entity bean with transaction type set to supports....
Kris

In the deployment descriptor file set the trasaction isolation level as TransactionReadUncommitted. It should solve your issue.

Similar Messages

Use same transaction in entity-bean and Datasource

Hello
I've got following problem. In my stateless container managed transaction Sessionbean i do some inserts and update on my container managed entity bean. In the same transaction I have to read some informations on the database. Some of those informations are already set by the entity bean, but not yet commited. Now I want to read them through a javax.sql.DataSource. But this Datasource doesn't use the same transaction as the session bean.
Question: Is it possible to let a Datasoucre use the same Transaction as Sessionbean?
(i work with WSAD 4.0.3)
Thanks

Hi,
You would have to check that you are using an XADataSource instance, instead of a 'regular' DataSource instance (which will not adopt the transaction started by the application server). In particular, the JNDI lookup name of the DataSource should actually point to an instance of XADataSource; a special type for container transactions.
The administration/deployment tools of the WS will allow you to do that, under Resource Factories or DataSources somewhere.
Both types look the same towards your application code, so your session bean is probably fine the way it is and does not need rewriting. It is merely in the setup of the WS server that the difference lies.
Best,
Guy
http://www.atomikos.com

How can I control the EJB's Transaction with entity bean

If I use entity bean, the Transaction is managed by container.and I want to create JDBC Connection by myselft ,not the Datasource,how is the transaction is controlled by the container,if transaction is not controlled ,how can I control it??

Hi,
If you want to control the transaction your self then you need to use javax.transaction.UserTransaction interface and methods defined by it.
Hope this helps
Vishal

Problem with transaction with Entity Beans in R2

I had a transaction (initiated by a session bean (requires new)) that takes two entity beans (two bank accounts) and trasfer funds from one to another. It looks like the container is waiting for the transaction, i don't know, here comes the exception I get (this code used to work with a lot of simultaneous clients with R1) :
com.evermind.server.ejb.TimeoutExpiredException: timeout expired waiting for an instance
at com.evermind.server.ejb.DBEntityWrapperPool.getWrapperInstance(DBEntityWrapperPool.java:189)
at com.evermind.server.ejb.DBEntityEJBHome.getWrapperInstance(DBEntityEJBHome.java:135)
error: Remote: Database error, IO failure: com.evermind.server.rmi.OrionRemoteException: Error enlisting connection resource: javax.transaction.RollbackException: The transaction has been marked for rollback (timed out); nested exception is:
javax.transaction.RollbackException: The transaction has been marked for rollback (timed out); nested exception is:
com.evermind.server.rmi.OrionRemoteException: Error enlisting connection resource: javax.transaction.RollbackException: The transaction has been marked for rollback (timed out); nested exception is:
javax.transaction.RollbackException: The transaction has been marked for rollback (timed out)
above goes the ejb-jar.xml
<?xml version="1.0"?>
<!DOCTYPE ejb-jar PUBLIC "-//Sun Microsystems, Inc.//DTD Enterprise JavaBeans 1.2//EN" "http://java.sun.com/j2ee/dtds/ejb-jar_1_2.dtd">
<ejb-jar>
<description>
</description>
<enterprise-beans>
<session>
<description>
</description>
<ejb-name>ContaFacadeEJB</ejb-name>
<home>contacorrente.ContaFacadeHome</home>
<remote>contacorrente.ContaFacade</remote>
<ejb-class>contacorrente.ContaFacadeBean</ejb-class>
<ejb-ref>
<ejb-ref-name>ContaCorrenteEJB</ejb-ref-name>
<ejb-ref-type>Entity</ejb-ref-type>
<home>contacorrente.ContaCorrenteHome</home>
<remote>contacorrente.ContaCorrente</remote>
</ejb-ref>
</session>
<entity>
<description>
</description>
<ejb-name>ContaCorrenteEJB</ejb-name>
<home>contacorrente.ContaCorrenteHome</home>
<remote>contacorrente.ContaCorrente</remote>
<ejb-class>contacorrente.ContaCorrenteBean</ejb-class>
<primkey-class>java.lang.String</primkey-class>
<reentrant>True</reentrant>
<persistence-type>Container</persistence-type>
<cmp-field><field-name>id_conta</field-name></cmp-field>
<cmp-field><field-name>saldo</field-name></cmp-field>
<cmp-field><field-name>senha</field-name></cmp-field>
<primkey-field>id_conta</primkey-field>
</entity>
</enterprise-beans>
<assembly-descriptor>
<container-transaction>
<method>
<ejb-name>ContaFacadeEJB</ejb-name>
<method-name>*</method-name>
</method>
<trans-attribute>RequiresNew</trans-attribute>
</container-transaction>
<container-transaction>
<method>
<ejb-name>ContaCorrenteEJB</ejb-name>
<method-name>*</method-name>
</method>
<trans-attribute>Mandatory</trans-attribute>
</container-transaction>
</assembly-descriptor>
</ejb-jar>
and the code of the beans (just the method used)
Entity (account)
public void debita(double valor) throws ContaCorrenteException
double saldoOld=saldo;
saldo=saldo-valor;
if (saldo<0)
throw new ContaCorrenteException("Saldo insuficiente:"+saldoOld);
Session :
public void transfere(String idConta1, String idConta2, double valor, String senha) throws ContaCorrenteException
try
Context cx=new InitialContext();
Object homeObject=cx.lookup("java:comp/env/ContaCorrenteEJB");
ContaCorrenteHome home=(ContaCorrenteHome) PortableRemoteObject.narrow(homeObject,ContaCorrenteHome.class);
ContaCorrente c1=null;
ContaCorrente c2=null;
try
c1=home.findByPrimaryKey(idConta1);
c2=home.findByPrimaryKey(idConta2);
if (!c1.getSenha().equals(senha)) { throw new ContaCorrenteException("Senha incorreta");}
catch(FinderException e)
System.out.println("erro ao localizar conta :"+e.getMessage());
context.setRollbackOnly();
throw new ContaCorrenteException("Conta inexistente");
catch(java.rmi.RemoteException e)
System.out.println("erro Remote: "+e.getMessage());
context.setRollbackOnly();
throw new ContaCorrenteException("Erro ao conectar objeto remoto");
try
c1.debita(valor);
c2.credita(valor);
catch(ContaCorrenteException e)
context.setRollbackOnly();
throw new ContaCorrenteException(e.getMessage());
catch(java.rmi.RemoteException e)
throw new ContaCorrenteException("Erro de conexco");
catch (NamingException e)
System.out.println("erro de localizagco:"+e.getMessage());
throw new ContaCorrenteException("Erro de acesso remoto na localizacao da conta");
please, someone help me...
Thanks in advance

I forgot : when i try to shut the server down i get the message :
Shutting down...
Error serializing bean: Deadlock detected, timing out call after 15 seconds wait for transaction [Transaction d9:fa:4f:b6:ff:ff:ff:ff:4a:0:0:0:0:0:0:0:0:4b:0:ec:6d:ce:c0:16]
Error serializing bean: Deadlock detected, timing out call after 15 seconds wait for transaction [Transaction d9:fa:4f:b6:ff:ff:ff:ff:4c:0:0:0:0:0:0:0:0:4d:0:ec:6d:d2:d9:d2]
Error serializing bean: Deadlock detected, timing out call after 15 seconds wait for transaction [Transaction d9:fa:4f:b6:ff:ff:ff:ff:4e:0:0:0:0:0:0:0:0:4f:0:ec:6d:d4:21:a3]
and it doesn't shutdown.

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]...
>

Need a Tx aware datasource when using CMT with BMP entity beans?

When using Containter-Managed Transactions with entity beans that have
          bean-managed persistence, do I need to use a transaction-aware datasource?
          Thanks,
          Ken Gertsen


Hi ad13217 and thanks for reply.
I'm sorry but my code is like this:
javax.naming.Context ctx=new javax.naming.InitialContext();
arguments was an error on copy, but it doesn't work.
Thanks
Fil

How to use same transaction when calling CMP entity beans and DAO (JDBC)

We are currently using Weblogic 8.1 SP2 with an Oracle 10g database (using XA thin and non-XA drivers).
We have a session bean that invokes an entity bean and a DAO (data access object pattern) in order to add data in 2 separate tables (account and history). Rows are added to the first (account) table using a CMP Entity bean while inserts are done in the 2nd (history) table using a DAO. Here is some pseudo code:
addHistorySessionBean (trans-attribute="Required")
begin
Step #1 - call addAccountEntityBean (trans- attribute="Required")
Step #2 - call addHistoryDAO (get datasource, connection)
end
The 2nd table (history) has a foreign key constraint to ensure that the corresponding key exists in the first (account) table. Unfortunately, DAO inserts on the 2nd (history) table fail with a foreign key constraint violation (INTEGRITY CONSTRAINT VIOLATION - PARENT KEY NOT FOUND!) since they cannot see the row added to the 1st (account) table in step #1 by the CMP entity bean.
How does one ensure that all this is done in a single transaction ? It appears that the app server creates two seperate transactions (one for the session bean facade and the entity bean and a 2nd transaction (when we retrieve a connection using the same data source JNDI name) for the DAO.
A post on server side suggested using a "<resource-ref>" in the session bean to tie the two potentially separate transactions together, but that does not work for us. However, I am not sure if we are doing that correctly. After we define the resource ref in the session facade bean, do we use the resource ref "name" attribute to lookup the datasource or do we still lookup the datasource by JNDI name ? Do we need to define the resource-ref tag in the entity bean also ?
Does Weblogic allow using a single transaction for this type of a scenario ? How does one specify within Weblogic that the same transaction should be utilized by the entity bean and any subsequent DAOs?
People have also suggested that we defer constraint checking until the transaction(s) are committed but that sounds like a work acount without addressing this issue. Would postponing the constraint checking in Oracle cause any additional overhead ?
Any suggestions with specific examples or documentation on how to address this issue will be gratefully appreciated.

Thanks for your suggestion. Unfortunately, this does not work since it appears that there are 2 separate transactions going on here. One, the original one initiated by the session bean and used by the entity bean and the other initiated by the DAO. Any other ideas appreciated.
Hi,
Try setting the delay-database-inserts tag to
ejbCreate in RDBMS descriptor file.
http://bernal/stage/wls/docs81/ejb/DDreference-cmp-jar
.html#1113981
vasanthi ramesh

Entity Bean can only use container-managed transaction demarcation?

In <<Designing Enterprise Application with J2EE 2nd>>
Section 2.3.3.3 Enterprise Bean Transactions,it says:Entity beans can only use container-managed transaction demarcation.
That means,i can not get UserTransaction from EJBContext.
Is that true?

Yes this is the requirement of the specs. Your ejb code generator should give you the error if you use usertransaction.
--Ashwani

Question about multiple RequiresNew in Entity Bean transaction

Hi I've got a problem concerning transactions:
In both cases I've got a CMP Entity Bean called "Account" with some mothods like
increaseBalance(double amount)
decreaseBalance(double amount)
transferMoney(double amount)
for all methods the TransactionAttribute is "RequiresNew". When calling first decreaseBalance(amount) and afterwords
increaseBalance(amount), bothfrom within transferMoney(amount). When setting entityContext.RollbackOnly()
I would expect this rollback doesn't undo my changes because they are in a different transaction, which has been comitted
when the methods finished, but both are rolled back.
I thought there are no "nested transactions" in J2EE. Isn't this one?
Thanks!
Martin

Ahhhh! Right! If I call "this.increase(balance)" from the AccountBean method "transferMoney", the container has no chance to create a new transaction, so the same transaction as in "transferMoney" is used. I didn't think about that, but of course...
So one should never call a bean method directly even when it is a method of the same instance the thread is currently in.
Thanks a lot!

Transactions entity bean

We have a rather large system where we get a lot of transactions. To
tune our system we decided to turn off transaction support for some
beans. (by setting the transaction attribute to NotSupported).
The system did not decrease the amount of transactions run so we
started wondering what was going on.
To test this we first implemented a small test application and then
also tested some examples provided by weblogic. In both cases we came
to the conclusion that when using entity beans transactions are always
run. We tested with wl6.1 and wl6.1sp3
A short example of some code:
Client:
for (int i=0; i<numBeans; i++) {
accounts = findOrCreateAccount("ID: "+i, i * 1000);
//transfer 1000 from account 10 to account 11
try {
accounts[10].withdraw(1000);
accounts[11].deposit(1000);
} catch (ProcessingErrorException e) {
log(" could not xfer cash");
} catch (RemoteException e) {
log(" could not xfer cash");
AccountBean (Entity Bean)
public double deposit(double amount) {
log("Depositing $" + amount + " into '" + accountId + "'");
if (weblogic.transaction.TxHelper.getTransaction() == null) {
log("dep no transaction");
else {
log("dep tx:
"+weblogic.transaction.TxHelper.getTransaction().getXID());
balance += amount;
if(true) {
log("throwing EJB EXCEPTION FOR TESTING");
throw new EJBException();
return balance;
ejb-jar.xml
<container-transaction>
<method>
<ejb-name>beanManaged</ejb-name>
     <method-intf>Remote</method-intf>
     <method-name>deposit</method-name>
</method>
<method>
<ejb-name>beanManaged</ejb-name>
     <method-intf>Remote</method-intf>
     <method-name>withdraw</method-name>
</method>
<trans-attribute>NotSupported</trans-attribute>
</container-transaction>
The first indication that a transaction was running was to check the
log:
deposit transaction: 370:971b99c458e3d95b
Then the transaction was rolled back and and we could see that the
account balance was unchanged which proves that a transaction was
running.
We can't be the first ones to discover this, but I can't find this
documented anywhere else.

If an entity bean is called and no transaction is in effect, the container
will
always start a transaction for its own use. Its not expensive to start a
transaction in WLS. The best architecture is almost always to
begin/commit
transactions before calling entity beans and let the entity beans inherit
the transaction, so that multiple calls to an entity bean are grouped into
a single transaction.
Seth
Daniel Bernholc wrote:
We have a rather large system where we get a lot of transactions. To
tune our system we decided to turn off transaction support for some
beans. (by setting the transaction attribute to NotSupported).
The system did not decrease the amount of transactions run so we
started wondering what was going on.
To test this we first implemented a small test application and then
also tested some examples provided by weblogic. In both cases we came
to the conclusion that when using entity beans transactions are always
run. We tested with wl6.1 and wl6.1sp3
A short example of some code:
Client:
for (int i=0; i<numBeans; i++) {
accounts = findOrCreateAccount("ID: "+i, i * 1000);
//transfer 1000 from account 10 to account 11
try {
accounts[10].withdraw(1000);
accounts[11].deposit(1000);
} catch (ProcessingErrorException e) {
log(" could not xfer cash");
} catch (RemoteException e) {
log(" could not xfer cash");
AccountBean (Entity Bean)
public double deposit(double amount) {
log("Depositing $" + amount + " into '" + accountId + "'");
if (weblogic.transaction.TxHelper.getTransaction() == null) {
log("dep no transaction");
else {
log("dep tx:
"+weblogic.transaction.TxHelper.getTransaction().getXID());
balance += amount;
if(true) {
log("throwing EJB EXCEPTION FOR TESTING");
throw new EJBException();
return balance;
ejb-jar.xml
<container-transaction>
<method>
<ejb-name>beanManaged</ejb-name>
<method-intf>Remote</method-intf>
<method-name>deposit</method-name>
</method>
<method>
<ejb-name>beanManaged</ejb-name>
<method-intf>Remote</method-intf>
<method-name>withdraw</method-name>
</method>
<trans-attribute>NotSupported</trans-attribute>
</container-transaction>
The first indication that a transaction was running was to check the
log:
deposit transaction: 370:971b99c458e3d95b
Then the transaction was rolled back and and we could see that the
account balance was unchanged which proves that a transaction was
running.
We can't be the first ones to discover this, but I can't find this
documented anywhere else.

Does WLS 6.1 sp2 allow (bean managed) entity beans to have transaction mode NOTSUPPORTED?

Hi,
I have created two bean managed entity beans, User and Role, abstracting users
and groups in a ldap base. A User may have more than one Role. This is represented
by a (bean managed) 1:many relationship directed from User to Role. For some weird
reasons I get a transaction rollback when reading data, when transactions are
turned on (REQUIRED).
While we where running WLS 6.1 sp1 we had no problems with this as we could set
transaction to NOTSUPPORTED for these two EJBs. Due to other hickups we had to
upgrade to sp2 and suddenly the error reappears leading me to believe that NOTSUPPORTED
isn't allowed anymore by the WLS. I know that NOTSUPPORTED isn't required by the
EJB spec, but containers may support it and obviously WLS used to do just that.
I have not seen any change in the release notes of sp2 that indicates that this
behaviour has changed.
Does anybody know if WLS really doesn't support NOTSUPPORTED for enity beans anymore
in sp2?
If anybody are curiuos or have any good ideas, the stacktrace I get is:
javax.ejb.TransactionRolledbackLocalException: EJB Exception:
- with nested exception:
[javax.ejb.EJBException
- with nested exception:
[weblogic.transaction.RollbackException: Unexpected exception in beforeCompletion:
sync=weblogic.ejb20.internal.TxManager$TxListener@1c2906 - with nested exception:
[java.util.ConcurrentModificationException]]]
Start server side stack trace:
java.rmi.RemoteException: EJB Exception: ; nested exception is:
     javax.ejb.TransactionRolledbackLocalException: EJB Exception:
- with nested exception:
[javax.ejb.EJBException
- with nested exception:
[weblogic.transaction.RollbackException: Unexpected exception in beforeCompletion:
sync=weblogic.ejb20.internal.TxManager$TxListener@1c2906 - with nested exception:
[java.util.ConcurrentModificationException]]]
java.util.ConcurrentModificationException
     at java.util.LinkedList$ListItr.checkForComodification(LinkedList.java:535)
     at java.util.LinkedList$ListItr.next(LinkedList.java:476)
     at weblogic.ejb20.manager.DBManager.beforeCompletion(DBManager.java:370)
     at weblogic.ejb20.internal.TxManager$TxListener.beforeCompletion(TxManager.java:481)
     at weblogic.transaction.internal.ServerSCInfo.callBeforeCompletions(ServerSCInfo.java:551)
     at weblogic.transaction.internal.ServerSCInfo.startPrePrepareAndChain(ServerSCInfo.java:88)
     at weblogic.transaction.internal.ServerTransactionImpl.localPrePrepareAndChain(ServerTransactionImpl.java:980)
     at weblogic.transaction.internal.ServerTransactionImpl.globalPrePrepare(ServerTransactionImpl.java:1504)
     at weblogic.transaction.internal.ServerTransactionImpl.internalCommit(ServerTransactionImpl.java:216)
     at weblogic.transaction.internal.ServerTransactionImpl.commit(ServerTransactionImpl.java:190)
     at weblogic.ejb20.internal.BaseEJBLocalObject.postInvoke(BaseEJBLocalObject.java:207)
     at com.takecargo.domainentities.role.RoleBean_1ipw6_ELOImpl.getName(RoleBean_1ipw6_ELOImpl.java:86)
     at com.takecargo.domainentities.role.RoleConverter.getVOforRoleLocal(RoleConverter.java:51)
Any kind of help would be appreciated:)
Regards,
Brynjar Glesnes

WLS support NotSupported on Entity Beans.
It looks like you've hit a bug in the EJB container where an internal Collection class has been modified while the
container is running through an iterator on it.
You should open a case with [email protected]
-- Rob
Brynjar Glesnes wrote:
Hi,
I have created two bean managed entity beans, User and Role, abstracting users
and groups in a ldap base. A User may have more than one Role. This is represented
by a (bean managed) 1:many relationship directed from User to Role. For some weird
reasons I get a transaction rollback when reading data, when transactions are
turned on (REQUIRED).
While we where running WLS 6.1 sp1 we had no problems with this as we could set
transaction to NOTSUPPORTED for these two EJBs. Due to other hickups we had to
upgrade to sp2 and suddenly the error reappears leading me to believe that NOTSUPPORTED
isn't allowed anymore by the WLS. I know that NOTSUPPORTED isn't required by the
EJB spec, but containers may support it and obviously WLS used to do just that.
I have not seen any change in the release notes of sp2 that indicates that this
behaviour has changed.
Does anybody know if WLS really doesn't support NOTSUPPORTED for enity beans anymore
in sp2?
If anybody are curiuos or have any good ideas, the stacktrace I get is:
javax.ejb.TransactionRolledbackLocalException: EJB Exception:
- with nested exception:
[javax.ejb.EJBException
- with nested exception:
[weblogic.transaction.RollbackException: Unexpected exception in beforeCompletion:
sync=weblogic.ejb20.internal.TxManager$TxListener@1c2906 - with nested exception:
[java.util.ConcurrentModificationException]]]
Start server side stack trace:
java.rmi.RemoteException: EJB Exception: ; nested exception is:
javax.ejb.TransactionRolledbackLocalException: EJB Exception:
- with nested exception:
[javax.ejb.EJBException
- with nested exception:
[weblogic.transaction.RollbackException: Unexpected exception in beforeCompletion:
sync=weblogic.ejb20.internal.TxManager$TxListener@1c2906 - with nested exception:
[java.util.ConcurrentModificationException]]]
java.util.ConcurrentModificationException
at java.util.LinkedList$ListItr.checkForComodification(LinkedList.java:535)
at java.util.LinkedList$ListItr.next(LinkedList.java:476)
at weblogic.ejb20.manager.DBManager.beforeCompletion(DBManager.java:370)
at weblogic.ejb20.internal.TxManager$TxListener.beforeCompletion(TxManager.java:481)
at weblogic.transaction.internal.ServerSCInfo.callBeforeCompletions(ServerSCInfo.java:551)
at weblogic.transaction.internal.ServerSCInfo.startPrePrepareAndChain(ServerSCInfo.java:88)
at weblogic.transaction.internal.ServerTransactionImpl.localPrePrepareAndChain(ServerTransactionImpl.java:980)
at weblogic.transaction.internal.ServerTransactionImpl.globalPrePrepare(ServerTransactionImpl.java:1504)
at weblogic.transaction.internal.ServerTransactionImpl.internalCommit(ServerTransactionImpl.java:216)
at weblogic.transaction.internal.ServerTransactionImpl.commit(ServerTransactionImpl.java:190)
at weblogic.ejb20.internal.BaseEJBLocalObject.postInvoke(BaseEJBLocalObject.java:207)
at com.takecargo.domainentities.role.RoleBean_1ipw6_ELOImpl.getName(RoleBean_1ipw6_ELOImpl.java:86)
at com.takecargo.domainentities.role.RoleConverter.getVOforRoleLocal(RoleConverter.java:51)
Any kind of help would be appreciated:)
Regards,
Brynjar Glesnes

Use direct JDBC with CMP entity bean in one transaction

I am trying to use direct JDBC call with CMP entity bean within a session
bean method that requires transaction. The problem is that it appears these
are not in the same transaction. When I use the JDBC call, the CMP entity
bean update to the DB has not been committed yet.
We are using Weblogic 5.1 SP6. The DB is Oracle.
What I do for the JDBC is get a new connection from the pool using weblogic
jdbc pool driver.
Any help would be appreciated.
Patrick

Hi. You can do JDBC and invoke CMP EJBs and have this all treated
as one transaction, if your hand-written code explicitly starts
a JTS transaction, then uses the jts driver or a TxDataSource to
get the JDBC connection. Then your code can call transactional
EJBs and their work will be included in the transaction you started.
Assuming the bean work went OK, and your manual JDBC went OK, you
can manually commit the UserTransaction at that time. This is 5.1
talk. For 6.0, with @PC, this may be even easier...
Joe
Patrick Shen wrote:
>
But if I do that, then they would not be in the same transaction anymore.
Is there any way to use JDBC with CMP Entity bean in the same transaction?
Patrick
"L'artiste" <[email protected]> wrote in message
news:[email protected]...
Are you calling all the CMP create in the session Bean ? If so, beforeyou
make the JDBC call from the session bean, the CMP in 2. should commit. Try
to set its attribute to TX_REQUIRES_NEW. This way, the calling client will
block until this transaction is done (committed) before the execution
continues. There might be some overhead involved in doing so if you are
anticipating a lot of users.
"Patrick Shen" <[email protected]> wrote in message
news:[email protected]...
What I am trying to do is:
In a Session bean method -
1. create a new CMP entity bean (a new row in DB table)
2. create another new CMP entity bean that uses previous bean as foreignkey
3. use JDBC to update the row just created
And all these 3 calls have to be in one transaction.
Thanks,
Patrick
"L'artiste" <[email protected]> wrote in message
news:[email protected]...
Can you give a little bit more information?
Do you have methods in your session bean that creates this CMP entitybeans?
It looks like
you might wanna try to change the isolation level to
TRANSACTION_READ_COMITTED
to preven dirty_read.
"Patrick Shen" <[email protected]> wrote in message
news:[email protected]...
I am trying to use direct JDBC call with CMP entity bean within a
session
bean method that requires transaction. The problem is that it
appears
these
are not in the same transaction. When I use the JDBC call, the CMP
entity
bean update to the DB has not been committed yet.
We are using Weblogic 5.1 SP6. The DB is Oracle.
What I do for the JDBC is get a new connection from the pool usingweblogic
jdbc pool driver.
Any help would be appreciated.
Patrick
PS: Folks: BEA WebLogic is expanding rapidly, with both entry and advanced positions
for people who want to work with Java, XML, SOAP and E-Commerce infrastructure products.
We have jobs at Nashua NH, Liberty Corner NJ, San Francisco and San Jose CA.
Send resumes to [email protected]

Entity beans caching non-persistent data between transactions

Some of the properties in our entity bean implementation classes are not declared
in our descriptor files, and therefore, are non-persistent (we are using container-managed
persistence); I will refer to these properties as "non-persistent properties".
In WebLogic 5.1, we've noticed that the non-persistent properties are cached in
between transactions. For instance, I ask for a particular Person (Person(James)),
and I set one of the non-persistent properties (Property(X)) inside Transaction(A).
In Transaction(B) (which is exclusive of Transaction(A)), I access Property(X)
and find that it is the same value as I had set in Transaction(A)- this gives
the appearance that non-persistent entity properties are being cached in between
transactions.
The same appears to hold true in WebLogic 7 SP1, however, we must use the "Exclusive"
concurrency-strategy to maintain this consistency.
I am worried that this assumption we are making of non-persistent properties is
not valid in all cases, and the documentation does not promise anything in the
way of such an assumption. I am worried that the container could kill the Person(James)
entity implementation instance in the pool after Transaction(A), and create a
new Person(James) instance to serve Transaction(B)- once that happens our assumption
fails.
"Database" concurrency strategy seems to fail our assumption on a regular basis,
but that makes sense, since the documentation states that the "database will maintain
the cache", and the container seems more willing to kill instances when they are
finished with, or create new instances for new transactions.
So my question is this: What is exactly guaranteed by the "Exclusive" concurrency-strategy?
Will the assumption that we've made above ever fail under this strategy?
Thanks in advance for any help.
Regards,
James

It simply means that there is only one entity bean instance per PK in the
server, and transaction which uses it locks it exclusively.
James DeFelice <[email protected]> wrote:
Thank you for the suggestion. I have considered taking this path, but before I
make a final decision, I was hoping to get a clear answer to the question that
I stated below:
What EXACTLY is guaranteed by the "Exclusive" concurrency-strategy? Maybe someone
from BEA knows?
"Cameron Purdy" <[email protected]> wrote:
To be safe: You should clear those values before the ejb load or set
them
after (or both).
Peace,
Cameron Purdy
Tangosol, Inc.
http://www.tangosol.com/coherence.jsp
Tangosol Coherence: Clustered Replicated Cache for Weblogic
"James DeFelice" <[email protected]> wrote in message
news:[email protected]...
Some of the properties in our entity bean implementation classes arenot
declared
in our descriptor files, and therefore, are non-persistent (we areusing
container-managed
persistence); I will refer to these properties as "non-persistentproperties".
In WebLogic 5.1, we've noticed that the non-persistent properties arecached in
between transactions. For instance, I ask for a particular Person(Person(James)),
and I set one of the non-persistent properties (Property(X)) insideTransaction(A).
In Transaction(B) (which is exclusive of Transaction(A)), I accessProperty(X)
and find that it is the same value as I had set in Transaction(A)-this
gives
the appearance that non-persistent entity properties are being cachedin
between
transactions.
The same appears to hold true in WebLogic 7 SP1, however, we must usethe
"Exclusive"
concurrency-strategy to maintain this consistency.
I am worried that this assumption we are making of non-persistentproperties is
not valid in all cases, and the documentation does not promise anythingin
the
way of such an assumption. I am worried that the container could killthe
Person(James)
entity implementation instance in the pool after Transaction(A), andcreate a
new Person(James) instance to serve Transaction(B)- once that happensour
assumption
fails.
"Database" concurrency strategy seems to fail our assumption on a regularbasis,
but that makes sense, since the documentation states that the "databasewill maintain
the cache", and the container seems more willing to kill instanceswhen
they are
finished with, or create new instances for new transactions.
So my question is this: What is exactly guaranteed by the "Exclusive"concurrency-strategy?
Will the assumption that we've made above ever fail under this strategy?
Thanks in advance for any help.
Regards,
James
Dimitri

Does Entity Bean allows Programmatic Transactions.

Hi,
I would like to know whether Entity beans allows Programmatic transactions. If they are not allowing then, if we want to abort the transactions then how we can do that.
Regards,
Satish. G

In case ur application throws runtime exception u need not worry about aborting the transaction. container takes care. suppose based on some condition (or possibly application exception where container won't do rollback automatically) if u want to abort / rollback the transaction you can call setRollbackOnly() of EntityContext which informs the container not to commit the transaction
- Paul

Multiple create methods of entity beans in single transcation

Hi,
I have some entity beans with CMR. I am managing these entity beans with a Stateful session bean whose transaction type is Container Managed for all its methods.
In one particular method of this Session bean I am calling two entity bean's create method. i.e I am creating two entity beans through home.create() methods. There are two home.create() methods one after another inside a try catch block.
I want that the entire operation be under just one transcation so i have also given the transaction attribute as Required for all methods of Session bean and Entity Beans.
However if i pass invalid parameters to second create method so that it generates exception then still the first create statement is successful and database is updated.
what i want is that the first create also should be roll backed.
How can i acheive this through Container Managed Transaction Session Bean?

Hi Ashwini,
"Ashwini" <[email protected]> wrote in message news:400291af$[email protected]..
I have some entity beans with CMR. I am managing these entity beans with a Stateful session bean whose transactiontype is Container Managed for all its methods.
>
In one particular method of this Session bean I am calling two entity bean's create method. i.e I am creatingtwo entity beans through home.create() methods. There are two home.create() methods one after another inside a try catch
block.
>
I want that the entire operation be under just one transcation so i have also given the transaction attribute asRequired for all methods of Session bean and Entity Beans.
>
However if i pass invalid parameters to second create method so that it generates exception then still the firstcreate statement is successful and database is updated.
what i want is that the first create also should be roll backed.
How can i acheive this through Container Managed Transaction Session Bean?o Do you use TXDatasource with your entity beans?
o In CMT transactions are automatically rolled back only when RuntimeExceptions
are thrown. What kind of exception is thrown in your case?
Regards,
Slava Imeshev

Transaction on Entity Bean

Similar Messages

Maybe you are looking for