Thanks Jim. Of course I can show you some code. We have this problem in our
own examples but to keep things simple, let's use a slightly modified
version of the Jonas samples. It's a bit lengthy. Sorry.
Here is a code snippet from the ClientAccount.java using AccountImplBean
(Container Managed Persistence)
...snip
// List existing Accounts
System.out.println("Getting the list of existing accounts in database");
accountList(home);
// Create a first Account
System.out.println("Creating a new Account in database");
Account a1 = null;
try {
a1 = home.create(109, "John Smith", 0);
} catch (Exception e) {
System.err.println("Cannot create Account: " + e);
System.exit(2);
}
// Find a second Account
System.out.println("Finding an Account by its number in database");
Account a2 = null;
try {
a2 = home.findByNumber(19);
} catch (Exception e) {
System.err.println("Cannot find Account: " + e);
System.exit(2);
}
// First transaction (committed):
// transfert 100 from a2 to a1
System.out.println("Starting a first transaction, that will be
committed");
try {
double value = 100.00;
utx.begin();
a1.setBalance(value);
a2.setBalance(-value);
utx.commit();
} catch (Exception e) {
System.err.println("exception during 1st Tx: " + e);
System.exit(2);
}
...
// List existing Accounts
System.out.println("Getting the new list of accounts in database");
accountList(home);
If no record is locked the output of the client Program is:
Getting a UserTransaction object from JNDI
Connecting to the AccountHome
Getting the list of existing accounts in database
0 Testdatensatz nr. 0 0.0
... (more records)
19 Testdatensatz nr. 19 500.0
Creating a new Account in database
Finding an Account by its number in database
Starting a first transaction, that will be committed
Starting a second transaction, that will be rolled back
Getting the new list of accounts in database
0 Testdatensatz nr. 0 0.0
... (more records)
19 Testdatensatz nr. 19 400.0
109 John Smith 100.0
Removing Account previously created in database
ClientAccount terminated
As expected, at the end of the program accno 19 has a reduced balance
(500->400). Everything is ok. But if accno 19 is locked by another program,
the output looks like this. (I reset the value to 500 prior to this run):
Getting a UserTransaction object from JNDI
Connecting to the AccountHome
Getting the list of existing accounts in database
0 Testdatensatz nr. 0 0.0
... (more records)
19 Testdatensatz nr. 19 500.0
Creating a new Account in database
Finding an Account by its number in database
Starting a first transaction, that will be committed
Starting a second transaction, that will be rolled back
Getting the new list of accounts in database
0 Testdatensatz nr. 0 0.0
... (more records)
19 Testdatensatz nr. 19 500.0
109 John Smith 100.0
Removing Account previously created in database
ClientAccount terminated
As you can see the balance of accno 19 is not reduced due to an SQLException
that occured. You can see the SQLException in the Server trace:
JOnAS - Version 1.4.1
JDBC DataSource informix_jdbc_1 is mapped on informix.properties
EJBHome:samples.eb.BullAccountImplBeanAccountHome for AccountImplBean
available
Failed to store bean to database
java.sql.SQLException: Could not position within a table
(messer.accountsample).
(-107)ISAM error: record is locked.
at com.informix.jdbc.IfxSqli.errorDone(IfxSqli.java)
at com.informix.jdbc.IfxSqli.receiveError(IfxSqli.java)
at com.informix.jdbc.IfxSqli.receiveMessage(Compiled Code)
at com.informix.jdbc.IfxSqli.executeCommand(IfxSqli.java)
at com.informix.jdbc.IfxResultSet.executeUpdate(IfxResultSet.java)
at
com.informix.jdbc.IfxStatement.executeUpdateImpl(IfxStatement.java)
at
com.informix.jdbc.IfxPreparedStatement.executeUpdate(IfxPreparedStatement.ja
va)
at
samples.eb.BullAccountImplBeanAccount.storeData(BullAccountImplBeanAccount.j
ava:319)
at
com.bull.ejb.EntitySynchroImpl.beforeCompletion(EntitySynchroImpl.jav
a:93)
at com.bull.jta.SubCoordinator.doBeforeCompletion(Compiled Code)
at
com.bull.jta.SubCoordinator.commit_one_phase(SubCoordinator.java:195)
at com.bull.jtm.ControlImpl.commit(ControlImpl.java:335)
at com.bull.jtm.ControlImpl_Skel.dispatch(Unknown Source)
at sun.rmi.server.UnicastServerRef.oldDispatch(Compiled Code)
at sun.rmi.server.UnicastServerRef.dispatch(Compiled Code)
at sun.rmi.transport.Transport$1.run(Compiled Code)
at java.security.AccessController.doPrivileged(Native Method)
at sun.rmi.transport.Transport.serviceCall(Compiled Code)
at sun.rmi.transport.tcp.TCPTransport.handleMessages(Compiled Code)
at
sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport
.java:607)
at java.lang.Thread.run(Thread.java:479)
EntitySynchroImpl.beforeCompletion() : java.rmi.RemoteException: Failed to
store bean to database; nested exception is:
java.sql.SQLException: Could not position within a table
(messer.accountsample).
(-107)ISAM error: record is locked.
The bad thing is, that the client tries hard to catch the Exception but does
not get anything.
try {
double value = 100.00;
utx.begin();
a1.setBalance(value);
a2.setBalance(-value);
utx.commit();
} catch (Exception e) {
System.err.println("exception during 1st Tx: " + e);
System.exit(2);
}
Are we doing somthing stupid? We will be very happy for your help.
Albert
> -----Urspr�ngliche Nachricht-----
> Von: Jim Richards [mailto:[EMAIL PROTECTED]]
> Gesendet am: Freitag, 29. Oktober 1999 03:05
> An: [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Betreff: Re: AW: Entity set() throws SQLException but never caught
>
> At 03:07 PM 28/10/99 +0200, Albert Brotzer wrote:
> >Sorry, this is not an answer to your problem. But we have a
> similar problem.
> >An SQLException occurs during the update of an entity bean, because the
> >record has been locked by an other user in the database. The
> Exception can
> >be seen in the server trace output as a java.sql.SQLException,
> but neither
> >the session bean nor the client get the RemoteException. They
> still believe
> >everything went ok.
>
> I don't believe that a RemoteException hsould be thrown for this sort of
> error. If a method in your bean (entity or session) throws an application
> exception (in this case SQLException) then that exception is propigated
> back to the client.
>
> I use this a lot when a session bean's business rules are violated, it
> throws back an application exception to let the client know that there
> was a business error.
>
> Can you post some code, it would help us ...
>
>
> --
> Subvert the dominant paradigm
> http://www.cyber4.org/members/grumpy/index.html
>
