Are these the non-transactional connections that OpenJPA is using to find the
id values for the entities? I think that's how it works.
On Feb 1, 2013, at 12:05 PM, Chris Wolf <cwolf.a...@gmail.com> wrote:
> Kevin,
>
> I finally got past the issue of running out of connections - I simply
> configured connections pooling via DBCP and the problem went away. I
> still consider this a "work-around" because if I have a single
> process/thread persisting entities, I would expect each step of the
> way to complete in a synchronous fashion and be able to use just one
> connection to do that.
>
> Before I tried configuring connection pooling, I was trying to isolate
> the code in OpenJPA that was using up all the connections and it
> appears to be occurring in the OpenJPA sequence generator code, in or
> about:
>
> org.apache.openjpa.kernel.StateManagerImpl.assignObjectId()
> org.apache.openjpa.kernel.JDBCStoreManager.assignObjectId()
> org.apache.openjpa.kernel.AbstractJDBCSeq.next()
> org.apache.openjpa.kernel.NativeJDBCSeq.nextInternal()
>
> My entity's annotations that invoke this are:
>
> @Id
> @SequenceGenerator(name="MARKET_DATA_MARKETDATAID_GENERATOR",
> sequenceName="MARKET_DATA_ID_SEQ")
> @GeneratedValue(strategy=GenerationType.SEQUENCE,
> generator="MARKET_DATA_MARKETDATAID_GENERATOR")
> @Column(name="MARKET_DATA_ID", unique=true, nullable=false,
> precision=19)
> public long getMarketDataId() {
> return this.marketDataId;
> }
>
>
> For now, I will just hope connection pooling will be sufficient to
> solve this issue, but I am wondering if your unit tests are running
> with pooling or not? If they are, you may be missing a problem.
>
> Thanks,
>
> Chris
>
>
>
> On Thu, Jan 31, 2013 at 5:59 PM, Chris Wolf <cwolf.a...@gmail.com> wrote:
>> Kevin,
>>
>> Thanks again, I'll look into the logging thing later - you're right
>> that I'm more focused on just getting persistence to work and so I'm
>> using the debugger. For now, it's just a JSE app, so no JTA yet (but
>> that's what's targeted).
>>
>> So in addition to the programmatic transaction management via Spring
>> JpaTransactionManager, ( which
>> suppressed the out-of-connections issue but silently didn't write to
>> the DB), I tried a third approach -
>> Spring-managed transactions via Spring's TransactionTemplate and
>> callbacks, but that only got me back to where
>> I started, which is the connections running out again, plus hideous
>> code, as you can see, below.
>>
>>
>> Ok, I'll keep hammering away at it. Thanks,
>>
>> -Chris
>>
>>
>> static void saveToDB(final List<MdBaseData> data) throws Exception {
>> EntityManagerFactory emf = Persistence
>> .createEntityManagerFactory("marketdata");
>>
>> final JpaTemplate jpaTempl = new JpaTemplate(emf);
>> jpaTempl.afterPropertiesSet();
>>
>> JpaTransactionManager jpaTxMgr = new
>> JpaTransactionManager(emf);
>> jpaTxMgr.afterPropertiesSet();
>>
>> final TransactionTemplate txTmpl = new
>> TransactionTemplate(jpaTxMgr);
>> txTmpl.afterPropertiesSet();
>>
>> TransactionStrategy txStrategy = new TransactionStrategy() {
>> @SuppressWarnings("deprecation")
>> public Object execute(final JpaCallback<?> callback) {
>> return txTmpl.execute(new
>> TransactionCallback<Object>() {
>> public Object
>> doInTransaction(TransactionStatus status) {
>> return jpaTempl.execute(new
>> JpaCallback<Object>() {
>> public Object
>> doInJpa(EntityManager entityManager)
>>
>> throws PersistenceException {
>> return
>> callback.doInJpa(entityManager);
>> }
>> });
>> }
>> });
>> }
>> };
>>
>> txStrategy.execute(new JpaCallback<Object>() {
>> @Override
>> public Object doInJpa(EntityManager em) throws
>> PersistenceException {
>> for (MdBaseData bd : data) {
>> em.persist(bd);
>> }
>> return null; // writing to db, not reading...
>> }
>> });
>> }
>>
>> On Thu, Jan 31, 2013 at 5:19 PM, Kevin Sutter <kwsut...@gmail.com> wrote:
>>>> Not certain what you meant by "join EM to the transaction".
>>> If an EM is created without knowledge of a containing JTA transaction, then
>>> the EM and the JTA transaction won't automatically be linked. Thus, if you
>>> start the transaction after the EM was created, you can use the
>>> EM.joinTransaction() method to get the two hooked up. This is, of course,
>>> assuming that the Spring-initiated transaction is a JTA transaction. If
>>> it's not, then you'll have to reference the Spring documentation to figure
>>> out how the EM and transaction are linked.
>>>
>>>> BTW, I don't know if you noticed my previous post about logging, but I
>>> tried setting openjpa.Log = slf4j
>>> Yes, I did notice. But, since you seemed to have been making progress, I
>>> figured you had figured something out... I'm not a slf4j expert, but I do
>>> know other users have had success with integrating openjpa with slf4j. I
>>> would guess it's an issue with the properties you are setting and how they
>>> get mapped to OpenJPA's properties. If you are setting properties like
>>> this:
>>>
>>> log4j.category.openjpa.jdbc.JDBC=TRACE
>>>
>>> .. OpenJPA wouldn't know what to do with this. I would try setting the
>>> properties for OpenJPA's logging in the same format for the persistence.xml:
>>>
>>> <property name="openjpa.Log" value="openjpa.jdbc.JDBC=TRACE"/>
>>>
>>> At least that's what I would expect. Somehow the configuration would still
>>> have to map to properties that OpenJPA knows about. Otherwise, our tracing
>>> code wouldn't know when or what to trace. I know there's some mapping code
>>> like this for Log4J and WebSphere and maybe others. But, the combination
>>> of slf4j and log4j might be throwing things off... Just an idea.
>>>
>>> Kevin
>>>
>>>
>>> On Thu, Jan 31, 2013 at 3:43 PM, Chris Wolf <cwolf.a...@gmail.com> wrote:
>>>
>>>> On Thu, Jan 31, 2013 at 4:30 PM, Kevin Sutter <kwsut...@gmail.com> wrote:
>>>>> So, which do you want? Lots of connections, or data getting to the
>>>>> database? :-)
>>>>
>>>> Preferably the later. ;)
>>>>
>>>>>
>>>>> Try starting the spring transaction before creating the EM. Either that,
>>>>> or join the EM to the transaction.
>>>>
>>>> I tried the former - it didn't change the outcome. Not certain what
>>>> you meant by "join EM to the transaction".
>>>>
>>>>
>>>>
>>>> BTW, I don't know if you noticed my previous post about logging, but I
>>>> tried setting openjpa.Log = slf4j
>>>> and that didn't work - no errors, just no addtional output.
>>>>
>>>> Thanks for helping so far...
>>>>
>>>>>
>>>>> Kevin
>>>>>
>>>>> On Thu, Jan 31, 2013 at 3:26 PM, Chris Wolf <cwolf.a...@gmail.com>
>>>> wrote:
>>>>>
>>>>>> Kevin,
>>>>>>
>>>>>> Someone on the us...@apache.camel.org mailing list suggested that I
>>>>>> let Springframework manage the transactions, so I changed my code to
>>>>>> look like:
>>>>>>
>>>>>> The apparent connection "leak" went away, and no exceptions are
>>>>>> thrown, and I only see one connection being opened, as expected -
>>>>>> however, nothing goes into the database.
>>>>>>
>>>>>> static void saveToDB(List<MdBaseData> data) throws Exception {
>>>>>> EntityManagerFactory emf = Persistence
>>>>>>
>>>> .createEntityManagerFactory("marketdata");
>>>>>> JpaTransactionManager jpaTxMgr = new
>>>>>> JpaTransactionManager(emf);
>>>>>>
>>>>>>
>>>>>> EntityManager em =
>>>>>>
>>>>>> jpaTxMgr.getEntityManagerFactory().createEntityManager();
>>>>>> TransactionStatus txStatus =
>>>>>> jpaTxMgr.getTransaction(new
>>>>>> DefaultTransactionDefinition());
>>>>>> try {
>>>>>> //em.getTransaction().begin();
>>>>>> for (MdBaseData bd : data) {
>>>>>> em.persist(bd);
>>>>>> }
>>>>>> //em.getTransaction().commit();
>>>>>> jpaTxMgr.commit(txStatus);
>>>>>> } catch (Exception e) {
>>>>>> jpaTxMgr.rollback(txStatus);
>>>>>> e.printStackTrace();
>>>>>> } finally {
>>>>>> em.close();
>>>>>> }
>>>>>> }
>>>>>>
>>>>>> On Thu, Jan 31, 2013 at 3:49 PM, Chris Wolf <cwolf.a...@gmail.com>
>>>> wrote:
>>>>>>> Even more specifically, I drilled down into the guts of OpenJPA-2.1,
>>>>>>> into the call to
>>>>>>> EntityManager.getTransaction().begin();
>>>>>>>
>>>>>>> The place were all the connections are opened until exhausted is in:
>>>>>>>
>>>>>>> org.apache.openjpa.kernel.BrokerImpl.flush(int reason)
>>>>>>>
>>>>>>> There is a loop where the connections are all being opened:
>>>>>>>
>>>>>>> Collection mobjs = null;
>>>>>>> _flags |= FLAG_PRESTORING;
>>>>>>> try {
>>>>>>> if (flush) {
>>>>>>> // call pre store on all currently transactional objs
>>>>>>> for (Iterator itr = transactional.iterator();
>>>>>>> itr.hasNext();) //<=== EATING UP ALL CONNECTIONS
>>>>>>> ((StateManagerImpl)
>>>> itr.next()).beforeFlush(reason,
>>>>>> _call);
>>>>>>>
>>>>>>>
>>>>>>> Let me know if there's anything else I can to do help solve this
>>>> issue.
>>>>>>>
>>>>>>> Thanks,
>>>>>>>
>>>>>>> -Chris
>>>>>>>
>>>>>>> On Thu, Jan 31, 2013 at 3:18 PM, Chris Wolf <cwolf.a...@gmail.com>
>>>>>> wrote:
>>>>>>>> Kevin,
>>>>>>>>
>>>>>>>> I isolated where all the connections are opened at once - upon
>>>> calling
>>>>>>>> entityManager.getTransaction().commit();
>>>>>>>>
>>>>>>>> I assume this is correct from all the exampled I've seen so far...
>>>>>>>>
>>>>>>>> EntityManager entityManager =
>>>>>>>> entityManagerFactory.createEntityManager(); // here is where just one
>>>>>>>> connection is opened, as expected. (not using connection pool yet)
>>>>>>>> entityManager.getTransaction().begin();
>>>>>>>> for (MdBaseData bd : data) {
>>>>>>>> em.persist(bd);
>>>>>>>> }
>>>>>>>> entityManager.getTransaction().commit(); // here is where all the
>>>>>>>> connections are opened *****
>>>>>>>> entityManager.close();
>>>>>>>>
>>>>>>>> Note that the entity has a M2M to child entities (about 100 per
>>>>>>>> MdBaseData) via a link table.
>>>>>>>>
>>>>>>>> Thanks for any ideas,
>>>>>>>>
>>>>>>>> -Chris
>>>>>>>>
>>>>>>>> On Thu, Jan 31, 2013 at 1:56 PM, Kevin Sutter <kwsut...@gmail.com>
>>>>>> wrote:
>>>>>>>>> Hi Chris,
>>>>>>>>> Good to know your plans. Thanks.
>>>>>>>>>
>>>>>>>>> You can get almost all of the JDBC connection access via the JDBC
>>>>>> channel
>>>>>>>>> in our logging framework [1]. Unfortunately, I looked at the code
>>>> and
>>>>>> the
>>>>>>>>> constructors don't seem to have a log entry... :-( But, you do get
>>>>>> all of
>>>>>>>>> the closes, commits, rollbacks, etc -- all of the normal operations
>>>>>> through
>>>>>>>>> a Connection object. So, I'd start with that.
>>>>>>>>>
>>>>>>>>> Updating the Ctor for additional logging would be very easy to do.
>>>> I
>>>>>> would
>>>>>>>>> probably do it in the LoggingConnectionDecorator, like you thought.
>>>>>> If you
>>>>>>>>> have issues with building a version of OpenJPA for your testing,
>>>> ping
>>>>>> me
>>>>>>>>> back with the version of OpenJPA that you are using and maybe I can
>>>>>> find
>>>>>>>>> time to do a quick update. But, try the JDBC log channel first and
>>>>>> see if
>>>>>>>>> that gives you enough information for your specific scenario.
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> Kevin
>>>>>>>>>
>>>>>>>>> [1]
>>>>>>>>>
>>>>>>
>>>> http://people.apache.org/~mikedd/nightly.builds/apache-openjpa-2.3.0-SNAPSHOT/docs/docbook/manual.html#ref_guide_logging_channels
>>>>>>>>>
>>>>>>>>> On Thu, Jan 31, 2013 at 12:02 PM, Chris Wolf <cwolf.a...@gmail.com>
>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> I am fully aware that pooling is the way to go, but I want to just
>>>>>>>>>> prove out the simple case first. Also the final deployment will
>>>> be in
>>>>>>>>>> a JEE container, so it will be doing the pooling.
>>>>>>>>>>
>>>>>>>>>> I really wish there was a logging setting to trace acquire/release
>>>> of
>>>>>>>>>> JDBC Connections - I looked at the source for (I forget now,
>>>> something
>>>>>>>>>> like JDBCDatStore) it had logging but not of acquire/release of
>>>>>>>>>> Connections.
>>>>>>>>>>
>>>>>>>>>> What is this LoggingConnectionDecorator? would that help me log
>>>>>>>>>> connection activity? If so, how is it configured?
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>>
>>>>>>>>>> -Chris
>>>>>>>>>>
>>>>>>>>>> On Thu, Jan 31, 2013 at 12:19 PM, Kevin Sutter <kwsut...@gmail.com
>>>>>
>>>>>> wrote:
>>>>>>>>>>> Hi Chris,
>>>>>>>>>>> Normally, OpenJPA will only request a connection "on demand" [1].
>>>>>> As
>>>>>>>>>> each
>>>>>>>>>>> database access is requested, a connection is obtained, but then
>>>>>> it's
>>>>>>>>>>> released when we're done with it. Unless there is some
>>>> processing
>>>>>> or
>>>>>>>>>>> configuration that is telling OpenJPA to hang onto the
>>>>>> connection... If
>>>>>>>>>>> nothing jumps out at you, I would suggest tracing (maybe both
>>>>>> OpenJPA and
>>>>>>>>>>> database) to see why all of the connections are getting requested
>>>>>> and
>>>>>>>>>>> nothing is getting closed.
>>>>>>>>>>>
>>>>>>>>>>> As an aside, I would highly recommend the use of some type of
>>>>>> connection
>>>>>>>>>>> pooling. Overall, you will get much better performance if
>>>>>> connections
>>>>>>>>>> can
>>>>>>>>>>> be re-used instead of constantly dropping and re-creating
>>>>>> connections.
>>>>>>>>>>> Whether you use DBCP or Oracle pooling or some application
>>>> server's
>>>>>>>>>>> connection pooling mechanism, it doesn't really matter. But, I
>>>>>> would
>>>>>>>>>>> suggest using some connection pooling.
>>>>>>>>>>>
>>>>>>>>>>> Good luck,
>>>>>>>>>>> Kevin
>>>>>>>>>>>
>>>>>>>>>>> [1]
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>
>>>> http://people.apache.org/~mikedd/nightly.builds/apache-openjpa-2.3.0-SNAPSHOT/docs/docbook/manual.html#ref_guide_dbsetup_retain
>>>>>>>>>>>
>>>>>>>>>>> On Thu, Jan 31, 2013 at 10:51 AM, Chris Wolf <
>>>> cwolf.a...@gmail.com>
>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> If I process a small number of records, everything works,
>>>> however
>>>>>> when
>>>>>>>>>>>> I try to process a "real-world" number of records, I get an
>>>>>>>>>>>> "ORA-12519". At first, I thought it was an Oracle issue and
>>>> after
>>>>>>>>>>>> searching around and getting hits on "solutions" involving
>>>>>> increasing
>>>>>>>>>>>> Oracle sessions and processes (there are at least 125
>>>> configured),
>>>>>> I
>>>>>>>>>>>> was still getting "ORA-12519". I then tailed the TNS listener
>>>> log
>>>>>> and
>>>>>>>>>>>> saw that everytime my OpenJPA process ran, it would consume all
>>>> the
>>>>>>>>>>>> JDBC connections as if it was using connection pooling with some
>>>>>> high
>>>>>>>>>>>> min-connections setting.
>>>>>>>>>>>>
>>>>>>>>>>>> In fact, as the stack trace shows, it's only using
>>>>>>>>>>>> "SimpleDriveDataSource", which I thought didn't pool connections
>>>>>> and I
>>>>>>>>>>>> don't have the DBCP jar on my classpath, so why is OpenJPA
>>>> opening
>>>>>> all
>>>>>>>>>>>> these JDBC connections?
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Chris
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> 183 marketdata INFO [main] openjpa.Runtime - Starting
>>>> OpenJPA
>>>>>> 2.2.1
>>>>>>>>>>>> 214 marketdata INFO [main] openjpa.jdbc.JDBC - Using
>>>> dictionary
>>>>>>>>>>>> class "org.apache.openjpa.jdbc.sql.OracleDictionary".
>>>>>>>>>>>> Exception in thread "main" <openjpa-2.2.1-r422266:1396819 fatal
>>>>>> store
>>>>>>>>>>>> error> org.apache.openjpa.persistence.RollbackException:
>>>> Listener
>>>>>>>>>>>> refused the connection with the following error:
>>>>>>>>>>>> ORA-12519, TNS:no appropriate service handler found
>>>>>>>>>>>>
>>>>>>>>>>>> at
>>>>>>>>>>>>
>>>>>>>>>>
>>>>>>
>>>> org.apache.openjpa.persistence.EntityManagerImpl.commit(EntityManagerImpl.java:594)
>>>>>>>>>>>> at
>>>>>> ms.algo.adapt.test.BeanIODemo.saveToDB(BeanIODemo.java:153)
>>>>>>>>>>>> at
>>>>>> ms.algo.adapt.test.BeanIODemo.beanIOTest(BeanIODemo.java:127)
>>>>>>>>>>>> at
>>>> ms.algo.adapt.test.BeanIODemo.main(BeanIODemo.java:50)
>>>>>>>>>>>> Caused by: <openjpa-2.2.1-r422266:1396819 fatal general error>
>>>>>>>>>>>> org.apache.openjpa.persistence.PersistenceException: Listener
>>>>>> refused
>>>>>>>>>>>> the connection with the following error:
>>>>>>>>>>>> ORA-12519, TNS:no appropriate service handler found
>>>>>>>>>>>>
>>>>>>>>>>>> at
>>>>>>>>>>>>
>>>>>> org.apache.openjpa.jdbc.sql.DBDictionary.narrow(DBDictionary.java:4958)
>>>>>>>>>>>> at
>>>>>>>>>>>>
>>>>>>>>>>
>>>>>>
>>>> org.apache.openjpa.jdbc.sql.DBDictionary.newStoreException(DBDictionary.java:4918)
>>>>>>>>>>>> at
>>>>>>>>>>>>
>>>>>>>>>>
>>>>>>
>>>> org.apache.openjpa.jdbc.sql.SQLExceptions.getStore(SQLExceptions.java:136)
>>>>>>>>>>>> at
>>>>>>>>>>>>
>>>>>>>>>>
>>>>>>
>>>> org.apache.openjpa.jdbc.sql.SQLExceptions.getStore(SQLExceptions.java:110)
>>>>>>>>>>>> at
>>>>>>>>>>>>
>>>>>>>>>>
>>>>>>
>>>> org.apache.openjpa.jdbc.sql.SQLExceptions.getStore(SQLExceptions.java:62)
>>>>>>>>>>>> at
>>>>>>>>>>>>
>>>>>>>>>>
>>>>>>
>>>> org.apache.openjpa.jdbc.kernel.JDBCStoreManager.connect(JDBCStoreManager.java:971)
>>>>>>>>>>>> at
>>>>>>>>>>>>
>>>>>>>>>>
>>>>>>
>>>> org.apache.openjpa.jdbc.kernel.JDBCStoreManager.getConnection(JDBCStoreManager.java:240)
>>>>>>>>>>>> at
>>>>>>>>>>>>
>>>>>>>>>>
>>>>>>
>>>> org.apache.openjpa.jdbc.kernel.AbstractJDBCSeq.getConnection(AbstractJDBCSeq.java:163)
>>>>>>>>>>>> at
>>>>>>>>>>>>
>>>>>>>>>>
>>>>>>
>>>> org.apache.openjpa.jdbc.kernel.NativeJDBCSeq.allocateInternal(NativeJDBCSeq.java:217)
>>>>>>>>>>>> at
>>>>>>>>>>>>
>>>>>>>>>>
>>>>>>
>>>> org.apache.openjpa.jdbc.kernel.NativeJDBCSeq.nextInternal(NativeJDBCSeq.java:201)
>>>>>>>>>>>> at
>>>>>>>>>>>>
>>>>>>>>>>
>>>>>>
>>>> org.apache.openjpa.jdbc.kernel.AbstractJDBCSeq.next(AbstractJDBCSeq.java:60)
>>>>>>>>>>>> at
>>>>>>>>>>>>
>>>>>> org.apache.openjpa.util.ImplHelper.generateValue(ImplHelper.java:160)
>>>>>>>>>>>> at
>>>>>>>>>>>>
>>>>>>>>>>
>>>>>>
>>>> org.apache.openjpa.util.ImplHelper.generateFieldValue(ImplHelper.java:144)
>>>>>>>>>>>> at
>>>>>>>>>>>>
>>>>>>>>>>
>>>>>>
>>>> org.apache.openjpa.jdbc.kernel.JDBCStoreManager.assignField(JDBCStoreManager.java:778)
>>>>>>>>>>>> at
>>>>>>>>>>>>
>>>>>> org.apache.openjpa.util.ApplicationIds.assign(ApplicationIds.java:493)
>>>>>>>>>>>> at
>>>>>>>>>>>>
>>>>>> org.apache.openjpa.util.ApplicationIds.assign(ApplicationIds.java:469)
>>>>>>>>>>>> at
>>>>>>>>>>>>
>>>>>>>>>>
>>>>>>
>>>> org.apache.openjpa.jdbc.kernel.JDBCStoreManager.assignObjectId(JDBCStoreManager.java:762)
>>>>>>>>>>>> at
>>>>>>>>>>>>
>>>>>>>>>>
>>>>>>
>>>> org.apache.openjpa.kernel.DelegatingStoreManager.assignObjectId(DelegatingStoreManager.java:135)
>>>>>>>>>>>> at
>>>>>>>>>>>>
>>>>>>>>>>
>>>>>>
>>>> org.apache.openjpa.kernel.StateManagerImpl.assignObjectId(StateManagerImpl.java:600)
>>>>>>>>>>>> at
>>>>>>>>>>>>
>>>>>>>>>>
>>>>>>
>>>> org.apache.openjpa.kernel.SingleFieldManager.preFlushPC(SingleFieldManager.java:803)
>>>>>>>>>>>> at
>>>>>>>>>>>>
>>>>>>>>>>
>>>>>>
>>>> org.apache.openjpa.kernel.SingleFieldManager.preFlushPCs(SingleFieldManager.java:762)
>>>>>>>>>>>> at
>>>>>>>>>>>>
>>>>>>>>>>
>>>>>>
>>>> org.apache.openjpa.kernel.SingleFieldManager.preFlush(SingleFieldManager.java:664)
>>>>>>>>>>>> at
>>>>>>>>>>>>
>>>>>>>>>>
>>>>>>
>>>> org.apache.openjpa.kernel.SingleFieldManager.preFlush(SingleFieldManager.java:589)
>>>>>>>>>>>> at
>>>>>>>>>>>>
>>>>>>>>>>
>>>>>>
>>>> org.apache.openjpa.kernel.SingleFieldManager.preFlush(SingleFieldManager.java:505)
>>>>>>>>>>>> at
>>>>>>>>>>>>
>>>>>>>>>>
>>>>>>
>>>> org.apache.openjpa.kernel.StateManagerImpl.preFlush(StateManagerImpl.java:3028)
>>>>>>>>>>>> at
>>>>>>>>>>>>
>>>> org.apache.openjpa.kernel.PNewState.beforeFlush(PNewState.java:44)
>>>>>>>>>>>> at
>>>>>>>>>>>>
>>>>>>>>>>
>>>>>>
>>>> org.apache.openjpa.kernel.StateManagerImpl.beforeFlush(StateManagerImpl.java:1042)
>>>>>>>>>>>> at
>>>>>>>>>> org.apache.openjpa.kernel.BrokerImpl.flush(BrokerImpl.java:2114)
>>>>>>>>>>>> at
>>>>>>>>>>>>
>>>>>> org.apache.openjpa.kernel.BrokerImpl.flushSafe(BrokerImpl.java:2074)
>>>>>>>>>>>> at
>>>>>>>>>>>>
>>>>>>>>>>
>>>>>>
>>>> org.apache.openjpa.kernel.BrokerImpl.beforeCompletion(BrokerImpl.java:1992)
>>>>>>>>>>>> at
>>>>>>>>>>>>
>>>>>>>>>>
>>>>>>
>>>> org.apache.openjpa.kernel.LocalManagedRuntime.commit(LocalManagedRuntime.java:81)
>>>>>>>>>>>> at
>>>>>>>>>>>>
>>>> org.apache.openjpa.kernel.BrokerImpl.commit(BrokerImpl.java:1516)
>>>>>>>>>>>> at
>>>>>>>>>>>>
>>>>>>>>>>
>>>>>>
>>>> org.apache.openjpa.kernel.DelegatingBroker.commit(DelegatingBroker.java:933)
>>>>>>>>>>>> at
>>>>>>>>>>>>
>>>>>>>>>>
>>>>>>
>>>> org.apache.openjpa.persistence.EntityManagerImpl.commit(EntityManagerImpl.java:570)
>>>>>>>>>>>> ... 3 more
>>>>>>>>>>>> Caused by: java.sql.SQLException: Listener refused the
>>>> connection
>>>>>> with
>>>>>>>>>>>> the following error:
>>>>>>>>>>>> ORA-12519, TNS:no appropriate service handler found
>>>>>>>>>>>>
>>>>>>>>>>>> at
>>>>>>>>>> oracle.jdbc.driver.T4CConnection.logon(T4CConnection.java:517)
>>>>>>>>>>>> at
>>>>>>>>>>>>
>>>>>>>>>>
>>>>>>
>>>> oracle.jdbc.driver.PhysicalConnection.<init>(PhysicalConnection.java:557)
>>>>>>>>>>>> at
>>>>>>>>>> oracle.jdbc.driver.T4CConnection.<init>(T4CConnection.java:233)
>>>>>>>>>>>> at
>>>>>>>>>>>>
>>>>>>>>>>
>>>>>>
>>>> oracle.jdbc.driver.T4CDriverExtension.getConnection(T4CDriverExtension.java:29)
>>>>>>>>>>>> at
>>>>>>>>>> oracle.jdbc.driver.OracleDriver.connect(OracleDriver.java:556)
>>>>>>>>>>>> at
>>>>>>>>>>>>
>>>>>>>>>>
>>>>>>
>>>> org.apache.openjpa.jdbc.schema.SimpleDriverDataSource.getSimpleConnection(SimpleDriverDataSource.java:84)
>>>>>>>>>>>> at
>>>>>>>>>>>>
>>>>>>>>>>
>>>>>>
>>>> org.apache.openjpa.jdbc.schema.AutoDriverDataSource.getConnection(AutoDriverDataSource.java:39)
>>>>>>>>>>>> at
>>>>>>>>>>>>
>>>>>>>>>>
>>>>>>
>>>> org.apache.openjpa.jdbc.schema.SimpleDriverDataSource.getConnection(SimpleDriverDataSource.java:76)
>>>>>>>>>>>> at
>>>>>>>>>>>>
>>>>>>>>>>
>>>>>>
>>>> org.apache.openjpa.lib.jdbc.DelegatingDataSource.getConnection(DelegatingDataSource.java:118)
>>>>>>>>>>>> at
>>>>>>>>>>>>
>>>>>>>>>>
>>>>>>
>>>> org.apache.openjpa.lib.jdbc.DecoratingDataSource.getConnection(DecoratingDataSource.java:93)
>>>>>>>>>>>> at
>>>>>>>>>>>>
>>>>>>>>>>
>>>>>>
>>>> org.apache.openjpa.lib.jdbc.DelegatingDataSource.getConnection(DelegatingDataSource.java:118)
>>>>>>>>>>>> at
>>>>>>>>>>>>
>>>>>>>>>>
>>>>>>
>>>> org.apache.openjpa.jdbc.schema.DataSourceFactory$DefaultsDataSource.getConnection(DataSourceFactory.java:304)
>>>>>>>>>>>> at
>>>>>>>>>>>>
>>>>>>>>>>
>>>>>>
>>>> org.apache.openjpa.jdbc.kernel.JDBCStoreManager.connectInternal(JDBCStoreManager.java:982)
>>>>>>>>>>>> at
>>>>>>>>>>>>
>>>>>>>>>>
>>>>>>
>>>> org.apache.openjpa.jdbc.kernel.JDBCStoreManager.connect(JDBCStoreManager.java:967)
>>>>>>>>>>>> ... 31 more
>>>>>>>>>>>> Caused by: oracle.net.ns.NetException: Listener refused the
>>>>>> connection
>>>>>>>>>>>> with the following error:
>>>>>>>>>>>> ORA-12519, TNS:no appropriate service handler found
>>>>>>>>>>>>
>>>>>>>>>>>> at oracle.net.ns.NSProtocol.connect(NSProtocol.java:457)
>>>>>>>>>>>> at
>>>>>>>>>>>>
>>>> oracle.jdbc.driver.T4CConnection.connect(T4CConnection.java:1625)
>>>>>>>>>>>> at
>>>>>>>>>> oracle.jdbc.driver.T4CConnection.logon(T4CConnection.java:365)
>>>>>>>>>>>> ... 44 more
>>>>>>>>>>>>
>>>>>>>>>>
>>>>>>
>>>>
