Kevin,
Sorry I missed your reply. Let me try to get something together.
-Chris
On Mon, Feb 4, 2013 at 5:47 PM, Kevin Sutter <kwsut...@gmail.com> wrote:
> 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
>> >>>>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>
>> >>>>
>>
>>
