I'm using Atomikos essential transactions as my TM in my J2SE application.
I have the following code:
if (userTransaction.getStatus()== Status.STATUS_ACTIVE){
userTransaction.commit();
}
and then I see in the logs the following exception:
java.lang.IllegalStateException:
TM_UNIQUE_NAME0003000006 is no longer active but
in state TERMINATED at
com.atomikos.icatch.imp.CoordinatorImp.addParticipant(CoordinatorImp.java:615)
at
com.atomikos.icatch.imp.TransactionStateHandler.addParticipant(TransactionStateHandler.java:133)
at
com.atomikos.icatch.imp.TransactionStateHandler.committed(TransactionStateHandler.java:347)
at
com.atomikos.icatch.imp.TransactionStateHandler.commit(TransactionStateHandler.java:298)
at
com.atomikos.icatch.imp.CompositeTransactionImp.doCommit(CompositeTransactionImp.java:319)
at
com.atomikos.icatch.imp.CompositeTerminatorImp.commit(CompositeTerminatorImp.java:79)
at
com.atomikos.icatch.jta.TransactionImp.commit(TransactionImp.java:236)
at
com.atomikos.icatch.jta.TransactionManagerImp.commit(TransactionManagerImp.java:496)
at
com.atomikos.icatch.jta.UserTransactionImp.commit(UserTransactionImp.java:129)
at
com.mycompany.module.view.myOtherClass.transformMpr(myOtherClass.java:57)
at
java.util.Observable.notifyObservers(Unknown
Source) at
com.mycompany.module.model.myClass.notifyObservers(myClass.java:291)
at
com.mycompany.module.model.myClass.MultiStateEscalation.run(myClass.java:91)
at
java.util.concurrent.Executors$RunnableAdapter.call(Unknown
Source) at
java.util.concurrent.FutureTask$Sync.innerRun(Unknown
Source) at
java.util.concurrent.FutureTask.run(Unknown
Source) at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(Unknown
Source) at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(Unknown
Source) at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown
Source) at
java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown
Source) at
java.lang.Thread.run(Unknown Source)
Where line 57 in the myOtherClass is the line where I call commit() in the above code. userTransaction is an instance of UserTransaction.
What I can't understand is what does TERMINATED means? I couldn't find these classes in the Atomikos distribution (which is weird since their open source and I additionaly ran a text search for the string over all the sources) and terminated is not one of the statuses defined in javax.transaction.Status.
Has someone incountered this? How can I check if the userTransaction I'm holding is valid for commit?
Thanks,
Ittai
TERMINATED means committed or rolled back. In your case, most likely a timeout / rollback.
Try increasing the timeout if you can.
In general, checking the transaction state does not guarantee that the next line of code can commit. Committing is an application request that can fail due to timeouts and resource issues; otherwise you wouldn't need two-phase-commit :-)
Best
Related
I'm using Hibernate 1.4.191 along with Hibernate 4.3.1. My h2 connection url is dbc:h2:file:./h2/myDB - which is an embedded DB without MULTI_THREADED enabled. I'm running with MVCC on - as this is the default setting for 1.4.191.
Using this configuration in my application, I got the following stack trace while trying to execute an update HQL statement:
2017-07-11 19:38:48 SEVERE Could not set rounding style. org.hibernate.PessimisticLockException: could not execute statement
at org.hibernate.dialect.H2Dialect$2.convert(H2Dialect.java:342)
at org.hibernate.exception.internal.StandardSQLExceptionConverter.convert(StandardSQLExceptionConverter.java:49)
at org.hibernate.engine.jdbc.spi.SqlExceptionHelper.convert(SqlExceptionHelper.java:126)
at org.hibernate.engine.jdbc.spi.SqlExceptionHelper.convert(SqlExceptionHelper.java:112)
at org.hibernate.engine.jdbc.internal.ResultSetReturnImpl.executeUpdate(ResultSetReturnImpl.java:190)
at org.hibernate.hql.internal.ast.exec.BasicExecutor.doExecute(BasicExecutor.java:109)
at org.hibernate.hql.internal.ast.exec.BasicExecutor.execute(BasicExecutor.java:78)
at org.hibernate.hql.internal.ast.QueryTranslatorImpl.executeUpdate(QueryTranslatorImpl.java:445)
at org.hibernate.engine.query.spi.HQLQueryPlan.performExecuteUpdate(HQLQueryPlan.java:347)
at org.hibernate.internal.SessionImpl.executeUpdate(SessionImpl.java:1282)
at org.hibernate.internal.QueryImpl.executeUpdate(QueryImpl.java:118)
at de.oktopos.dataBase.receipts.converter.ReceiptConverter$29.runOperation(ReceiptConverter.java:1214)
at de.oktopos.dataBase.receipts.converter.ReceiptConverter$29.runOperation(ReceiptConverter.java:1210)
at de.oktopos.dataBase.tools.DatabaseOperationRunner.run(DatabaseOperationRunner.java:71)
at de.oktopos.dataBase.receipts.converter.ReceiptConverter.setRoundingStyle(ReceiptConverter.java:1226)
at de.oktopos.dataBase.receipts.converter.ReceiptCacheWriter.setRoundingStyle(ReceiptCacheWriter.java:99)
at de.oktopos.oktoDeskService.remote.OktoDeskModel.setRoundingStyle(OktoDeskModel.java:841)
at net.oktopos.cashdesk.DeskModelProcessor.setRoundingStyle(DeskModelProcessor.java:1648)
at sun.reflect.GeneratedMethodAccessor37.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at sun.rmi.server.UnicastServerRef.dispatch(Unknown Source)
at sun.rmi.transport.Transport$1.run(Unknown Source)
at sun.rmi.transport.Transport$1.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at sun.rmi.transport.Transport.serviceCall(Unknown Source)
at sun.rmi.transport.tcp.TCPTransport.handleMessages(Unknown Source)
at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(Unknown Source)
at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.lambda$run$0(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
Caused by: org.h2.jdbc.JdbcSQLException: Zeitüberschreitung beim Versuch die Tabelle zu sperren
Timeout trying to lock table ; SQL statement:
update Receipt set turnoverType=? [50200-191]
at org.h2.message.DbException.getJdbcSQLException(DbException.java:345)
at org.h2.message.DbException.get(DbException.java:168)
at org.h2.command.Command.filterConcurrentUpdate(Command.java:307)
at org.h2.command.Command.executeUpdate(Command.java:260)
at org.h2.jdbc.JdbcPreparedStatement.executeUpdateInternal(JdbcPreparedStatement.java:160)
at org.h2.jdbc.JdbcPreparedStatement.executeUpdate(JdbcPreparedStatement.java:146)
at org.hibernate.engine.jdbc.internal.ResultSetReturnImpl.executeUpdate(ResultSetReturnImpl.java:187)
... 29 more
Caused by: org.h2.jdbc.JdbcSQLException: Gleichzeitige Änderung in Tabelle "RECEIPT": eine andere Transaktion hat den gleichen Datensatz geändert oder gelöscht
Concurrent update in table "RECEIPT": another transaction has updated or deleted the same row [90131-191]
at org.h2.message.DbException.getJdbcSQLException(DbException.java:345)
at org.h2.message.DbException.get(DbException.java:168)
at org.h2.mvstore.db.MVTable.convertException(MVTable.java:898)
at org.h2.mvstore.db.MVSecondaryIndex.remove(MVSecondaryIndex.java:247)
at org.h2.mvstore.db.MVTable.removeRow(MVTable.java:677)
at org.h2.table.Table.updateRows(Table.java:487)
at org.h2.command.dml.Update.update(Update.java:145)
at org.h2.command.CommandContainer.update(CommandContainer.java:98)
at org.h2.command.Command.executeUpdate(Command.java:258)
... 32 more
Caused by: java.lang.IllegalStateException: Entry is locked [1.4.191/101]
at org.h2.mvstore.DataUtils.newIllegalStateException(DataUtils.java:773)
at org.h2.mvstore.db.TransactionStore$TransactionMap.set(TransactionStore.java:1031)
at org.h2.mvstore.db.TransactionStore$TransactionMap.remove(TransactionStore.java:989)
at org.h2.mvstore.db.MVSecondaryIndex.remove(MVSecondaryIndex.java:241)
... 37 more
Im trying to understand how this is possible. The stack trace seems to say that a lock could not be acquired because of another connection (50200). In particular it says that another connection concurrently updated the table (90131). But there can only be one connection because the database is embedded. Am I missing something here?
The the HQL query is basically executed as follows (minus error handling boilerplate, DBReceipt maps to receipt):
Session session = sessionFactory.openSession();
Transaction transaction = session.beginTransaction();
session.createQuery("UPDATE DBReceipt SET turnovertype = :turnovertype")
.setParameter("turnovertype", turnovertype)
.executeUpdate();
transaction.commit();
session.close();
There are of course many other database writes/reads in the background on different threads, but all use the same connection.
The error kept happening when the above part of the code was called. Even restarting the application did not help - the next call of the code would cause the same exception. Only dropping the DB helped.
I found the likely source of the problem after looking arround a bit in my code base.
I was namely creating a LockRequest and locking the a receipt in the receipt table. If this lock is never let go (because the transaction ends up in an infinite loop), then any update on the receipt table afterwards would lead to the stack trace above.
I solved the problem by removing the LockRequest (I couldn't find the source of the infinite loop). This was possible because we recently moved to locking that receipt on an application level, and also because there would be no problems in our application with optimistic locking.
Another work around to this problem would be to add a timeout to the lock, transaction, or session. However, my enviroment doesn't seem to support any of these - at least none of them worked in my tests.
I'm using in a Java project RMI + Hibernate and I'm experiencing problems related to NotUniqueException with the error "Different objects with the same identifier".
I've got several doubts:
I'm pretty surre that I don't copy nor create new objects with the same ide
ntifiers. Is it possible that RMI creates a new object from another one when I use it?
Which method is using Hibernate to know that two objects are the same? equals?
I know that Serializable is related to Hibernate but I don't know in what way?
How can I solve the "Differents objects error" using RMI at the same time?
Is it correct every time I use delete or save over an object use merge before?
The stack traces is:
org.orm.PersistentException: org.hibernate.NonUniqueObjectException: a different object with the same identifier value was already associated with the session: [dcl.Administrador#10]
at org.orm.PersistentSession.saveOrUpdate(PersistentSession.java:648)
at org.orm.PersistentManager.saveObject(PersistentManager.java:274)
at dcl.AdministradorDAO.save(AdministradorDAO.java:240)
at dcl.BdAdministrador.guardarAdministrador(BdAdministrador.java:62)
at dcl.BdAdministrador.actualizarAdministrador(BdAdministrador.java:109)
at dcl.BdPrincipal.actualizarAdministrador(BdPrincipal.java:555)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at sun.rmi.server.UnicastServerRef.dispatch(Unknown Source)
at sun.rmi.transport.Transport$1.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at sun.rmi.transport.Transport.serviceCall(Unknown Source)
at sun.rmi.transport.tcp.TCPTransport.handleMessages(Unknown Source)
at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(Unknown Source)
at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
Thanks in advance.
If you're doing something like returning a hibernate object from an RMI method, then passing it back into another one, then you'll potentially need to reattach the object to the session. (see What is the proper way to re-attach detached objects in Hibernate?).
Perhaps give some more info on what you're attempting if this doesn't help.
I'm trying to replicate the java guestbook example on Quercus on AppEngine and I'm getting an error having to do with preparing the query:
$greetings = $datastore->prepare($query)->asIterable();
I'm not a java developer so I can't make sense of the error trace. How can I get the greeting items without triggering this error?
Here is the entire error page:
HTTP ERROR 500
Problem accessing /index.php. Reason:
INTERNAL_SERVER_ERROR
Caused by:
java.lang.NullPointerException at
com.google.appengine.api.datastore.dev.LocalDatastoreService.next(LocalDatastoreService.java:1089)
at sun.reflect.GeneratedMethodAccessor8.invoke(Unknown Source) at
sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at
java.lang.reflect.Method.invoke(Unknown Source) at
com.google.appengine.tools.development.ApiProxyLocalImpl$AsyncApiCall.callInternal(ApiProxyLocalImpl.java:498)
at
com.google.appengine.tools.development.ApiProxyLocalImpl$AsyncApiCall.call(ApiProxyLocalImpl.java:452)
at
com.google.appengine.tools.development.ApiProxyLocalImpl$AsyncApiCall.call(ApiProxyLocalImpl.java:430)
at java.util.concurrent.Executors$PrivilegedCallable$1.run(Unknown
Source) at java.security.AccessController.doPrivileged(Native Method)
at java.util.concurrent.Executors$PrivilegedCallable.call(Unknown
Source) at java.util.concurrent.FutureTask$Sync.innerRun(Unknown
Source) at java.util.concurrent.FutureTask.run(Unknown Source) at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
If it's a null pointer exception then you are trying to access a method or property of a null object
First you need to check if $datastore is null, then if the return of the query is not null. Also you need to check if that error is on that particular line of code (maybe it fails somewhere else)
You can access the database at this link /_ah/admin. Maybe there is a corrupt entity in there
Loading classifier from D:\PROJECT\classifiers\NERDemo\classifiers\ner-eng-ie.crf-3-all2008.ser.gz ... done [2.0 sec].
Original Query was riot in India.
Parsing Queries and expanding tokens from the Ontologies..
{locations=[India], events=[riot]}
Search query is null
Something went wrong...
java.net.UnknownHostException: ajax.googleapis.com
at java.net.PlainSocketImpl.connect(Unknown Source)
at java.net.SocksSocketImpl.connect(Unknown Source)
at java.net.Socket.connect(Unknown Source)
at java.net.Socket.connect(Unknown Source)
at sun.net.NetworkClient.doConnect(Unknown Source)
at sun.net.www.http.HttpClient.openServer(Unknown Source)
at sun.net.www.http.HttpClient.openServer(Unknown Source)
at sun.net.www.http.HttpClient.<init>(Unknown Source)
at sun.net.www.http.HttpClient.New(Unknown Source)
at sun.net.www.http.HttpClient.New(Unknown Source)
at sun.net.www.protocol.http.HttpURLConnection.getNewHttpClient(Unknown Source)
at sun.net.www.protocol.http.HttpURLConnection.plainConnect(Unknown Source)
at sun.net.www.protocol.http.HttpURLConnection.connect(Unknown Source)
at sun.net.www.protocol.http.HttpURLConnection.getInputStream(Unknown Source)
at org.girs2.SearchHandler.makeQuery(SearchHandler.java:35)
at org.girs2.GIRS.search(GIRS.java:37)
at org.girs2.GIRS.main(GIRS.java:62)
Exception in thread "main" java.lang.NullPointerException
at org.girs2.GIRS.search(GIRS.java:44)
at org.girs2.GIRS.main(GIRS.java:62)
Looks like you probably have or had a DNS lookup failure. This tells you what happened:
java.net.UnknownHostException: ajax.googleapis.com
If you always get this exception and you can otherwise access this host by name, then I don't know what this could be, but odds are that this was a temporary DNS failure.
What should you do when you get this Exception? Well, if the address is one that you fully expect you should be able to get to -- such as this one -- then when you catch the Exception, you sleep for a while (perhaps 10 or 15 seconds, maybe even 30 or 60 seconds, depending on your application's needs) and try again.
If after several retries -- don't just retry forever! -- you still cannot reach the site, then log a reasonable complaint or otherwise complain that you cannot reach the site and have your application exit.
There's not much you can do when DNS fails except give up or wait and try again.
on Windows systems. I get the following NPE with the FileChooser. It is a known bug that is not fixed by sun yet. http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6342301
Does somebody know a workaround to prevent this exception?
Thanks.
André
Exception in thread "AWT-EventQueue-2" java.lang.NullPointerException
at
javax.swing.plaf.metal.MetalFileChooserUI$IndentIcon.getIconWidth(Unknown
Source) at javax.swing.SwingUtilities.layoutCompoundLabelImpl(Unknown
Source) at javax.swing.SwingUtilities.layoutCompoundLabel(Unknown
Source) at javax.swing.plaf.basic.BasicLabelUI.layoutCL(Unknown
Source) at
javax.swing.plaf.basic.BasicLabelUI.getPreferredSize(Unknown Source)
at javax.swing.JComponent.getPreferredSize(Unknown Source) at
javax.swing.plaf.basic.BasicListUI.updateLayoutState(Unknown Source)
at javax.swing.plaf.basic.BasicListUI.maybeUpdateLayoutState(Unknown
Source) at
javax.swing.plaf.basic.BasicListUI$Handler.valueChanged(Unknown
Source) at
javax.swing.DefaultListSelectionModel.fireValueChanged(Unknown Source)
at javax.swing.DefaultListSelectionModel.fireValueChanged(Unknown
Source) at
javax.swing.DefaultListSelectionModel.fireValueChanged(Unknown Source)
at javax.swing.DefaultListSelectionModel.changeSelection(Unknown
Source) at
javax.swing.DefaultListSelectionModel.changeSelection(Unknown Source)
at javax.swing.DefaultListSelectionModel.setSelectionInterval(Unknown
Source) at javax.swing.JList.setSelectedIndex(Unknown Source) at
javax.swing.plaf.basic.BasicComboPopup.setListSelection(Unknown
Source) at javax.swing.plaf.basic.BasicComboPopup.access$300(Unknown
Source) at
javax.swing.plaf.basic.BasicComboPopup$Handler.itemStateChanged(Unknown
Source) at javax.swing.JComboBox.fireItemStateChanged(Unknown Source)
at javax.swing.JComboBox.selectedItemChanged(Unknown Source) at
javax.swing.JComboBox.contentsChanged(Unknown Source)
In the bug report that you linked to, they also mention a workaround.
It seems to come down to calling the methods in a specific order.
Have you tried that?
A DESCRIPTION OF THE PROBLEM :
There appears to be an undocumented bad intereaction between
explicitely setting the UI and removing all file filters, even temporarily.
If the latter is done before setting the ui, trying to display a file dialog
will throw an exception but not if the ui was set prior to messing with
the filters. Maybe it is possible to make the code more robust against
this or to include a warning in the docs?
STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Run the attached program: it will not bomb. Then move the setUI
line to the bottom of the constructor and try again: it will.
So, now with registered account :)
The problem with these steps in the mentioned link is, that the look and feel and therefor the UI is set globaly in our software. So the UI is set before I'm able to manipulate the file filters.
Edit: Missunderstood the code for reproduction. The exampled works as mentioned. Thanks.
It looks like the workaround description says you should try to set the UI before manipulating the filters. Does this not work?
If that doesn't work, is it possible to create an instance of your manipulated FileFilters at the same point that you are setting your UI?