Correct, James. OpenJPA does use non-transactional datasources for
accessing the database during id generation processing (if it's
necessary). If a <non-jta-data-source> is defined, that will be used.
Otherwise, the openjpa.Connection2* properties will be used to access via
an additional connection.
Back to Chris' issue... I'm glad to hear that the use of DBCP is resolving
your issue -- or, at least, is providing a suitable workaround. And, as I
mentioned earlier, the use of a connection pooling mechanism is good
overall.
OpenJPA does use DBCP by default. Maybe we are missing a scenario with id
generation. If you could describe the specific scenario (better yet with a
junit test case), then maybe we can reproduce the issue and get it resolved.
Thanks,
Kevin
On Fri, Feb 1, 2013 at 11:13 AM, James Carman
<jcar...@carmanconsulting.com>wrote:
> 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
> >>>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>
> >>>>
>
>
