• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Long running thread updating Entity using EJB

 
Greenhorn
Posts: 6
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I'm trying to create a JavaEE application with the following structure: a long running thread continuously reads from a file the current temperature (the file is wrote by a python thread that read the temp from a sensor) and each time it persists the read temperature in an JPA Entity via an EJB.
The thread is launched by a servlet using a ManagedScheduledExecutorService injected via @Resource(name = "concurrent/scheduledExecutor") annotation.

The application works, but if I read the log in the Glassfish server I find a lot of the following two messages:

- The statement was aborted because it would have caused a duplicate key value in a unique or primary key constraint or unique index identified by ...
- Attempt to invoke when container is in Undeployed

What could be the reason behind?
 
Ranch Hand
Posts: 270
15
Android Angular Framework Spring AngularJS Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi, Sergio,
The message is claiming there are duplicate keys out there.  You should check your SQL statements (if you can dump them from JPA's EntityManager), or just think about what keys are being used.  If they are based on some coarse unit of time, you might have a clash for that reason.

Also, if it were me (and I don't know anything about your design), I would be thinking about how the servlet is getting its EJB proxy and how long it is keeping that open.  Is it injected, for instance?  If your two messages are not necessarily paired (they occur separately), this could explain the "undeployed" part.

Further, the 3.1 EJB standard allows for a singleton, and the singleton can be hooked up to a timer.  EJBs are never supposed to read or write directly to the filesystem, according to the spec, but people have been known to do that (shhh! ;-)).  But that's just a design suggestion.
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
reply
    Bookmark Topic Watch Topic
  • New Topic