About recording

51-60 of 199Refresh
JPA Doc
4

javax.persistence.PessimisticLockException

the execution stack trace. Fills in the execution stack trace. This method records within this Throwable object ... () method for this object. Remaining lines represent data previously recorded by the method
JPA Doc
4

javax.persistence.QueryTimeoutException

the execution stack trace. This method records within this Throwable object information ... . Remaining lines represent data previously recorded by the method fillInStackTrace(). The format
JPA Doc
4

javax.persistence.RollbackException

the execution stack trace. This method records within this Throwable object information about the current ... the result of the toString() method for this object. Remaining lines represent data previously recorded by
JPA Doc
4

javax.persistence.TransactionRequiredException

stack trace. Fills in the execution stack trace. This method records within this Throwable object ... data previously recorded by the method fillInStackTrace(). The format of this information depends
Forum
4

Wrong data stored in time only fields

100K records it will show up in about 1.5K records with no obvious pattern. Also it appears ... records and as you can see the startTime parameter is set to "31 Dec 1969 hh:mm:ss ... , but see further explanation of some odd values below. Here is the data used to create the 9 records: 2015-12-19 18:12:53,000
Forum
3

First query takes 4+ minutes to complete

query that we run on the DB which contains about 320,000 records of a single type of object. SQLite in comparison responds within few seconds on average with the same number of records. We hope ... thread: 1. The first EntityManager only adds records to the DB at a rate of 5 records per second. Each
Forum
3

OutofMemory error with Object DB 2.0

and inserts 200 records at a time. The transaction obtained from the PersistentManager is commited after persisting 200 records and then the same transaction object from the same PersistentManager ... (com.objectdb.jdo.PMImp) The application tries to persist records one by one and commits
Forum
3

performance limit

with large records sets. Our issue is with tables with 100.000+ records. Everything was OK when we had few thousand records. We have a simple SELECT statement which selects from a table with 100.000+ records by UserID atribute, tables have from 5 to 20 atributes. Usualy the results range from
Result
3

fillInStackTrace()

Method java.lang.Throwable Throwable fillInStackTrace() Fills in the execution stack trace. This method records within this Throwable object information about the current state of the stack frames for the current thread. Returns: a reference to this Throwable instance. Since: Java JDK1.0 See Also: java.lang.Throwable.printStackTrace()
JPA Doc
3

javax.persistence.Table

@Table(name="CUST", schema="RECORDS") public class Customer { ... } Since: JPA 1.0 String