JPA – EclipseLink – MySQL – @OneToMany

Today I was faced with a really strange problem concerning JPA, EclipseLink an MySQL. I have Service EJB (3.1) with some JPA Entity Beans. They are joined with @OneToMany constraints. I am deploying my application typically under GlassFish 3.1 with MySQL Database. Everything works fine so far. But in some really strange cases – long complex transactions with a lot of updates and inserts I got a JPA Exception like this:

[#|2014-09-25T17:21:01.989+0200|WARNING|glassfish3.1.2|org.eclipse.persistence.session.file:/opt/glassfish-3.1.2/glassfish/domains/domain2/applications/office/office-ejb-1.0.0_jar/_org.imixs.workflow.jee.jpa|_ThreadID=160;_ThreadName=Thread-2;|Local Exception Stack: 
Exception [EclipseLink-4002] (Eclipse Persistence Services - 2.3.2.v20111125-r10461): org.eclipse.persistence.exceptions.DatabaseException
Internal Exception: com.mysql.jdbc.exceptions.jdbc4.MySQLIntegrityConstraintViolationException: Cannot delete or update a parent row: a foreign key constraint fails (`mydatabase`.`ENTITY_WRITEACCESS`, CONSTRAINT `FK_ENTITY_WRITEACCESS_writeAccessList_ID` FOREIGN KEY (`writeAccessList_ID`) REFERENCES `WRITEACCESS` (`ID`))
Error Code: 1451
Call: DELETE FROM WRITEACCESS WHERE (ID = ?)
    bind => [1 parameter bound]
Query: DeleteObjectQuery(org.imixs.workflow.jee.jpa.WriteAccess@5aa4670a)

I was confronted with such error messages in the past and solved them by changing the transaction boundaries in my code by encapsulating some of the jpa stuff in separate methods with new transaction context.

But The real reason for this kind of error is an inaccurate mapping of the database schema in MySQL made by EclipseLink. My table ‘ENTITY_WRITEACCESS’ is a crosstable needed for a @OneToMany relationship of my JPA entity beans.  I never looked at the schema in detail, because in my opinion that is stuff of the OR-Mapper.
The problem was that per default no CascadeType is defined for a @OneToMany relationship. But even when you define a CascadeType like CascadeType.DELETE – which is also implied by CascadeType.ALL – to your entity beans this will not necessarily be reflected to the database schema generated from the OR-Mapper. When you look at the generated schema you’ll notice that ON DELETE CASCADE is not added to the constraint. When you alter your schema and Add ON DELETE CASCADE to actual tables this will fix the problem above.

Note that this all depends on the JPA implementors how the constrains are created. So take a look at your generated table schemas.

Warum Aufgabenmanagement scheitert

In der heutigen Arbeitswelt sind wir es gewohnt, komplexe Aufgabenstellungen in kleineren oder größeren Teams zu lösen. Probleme, Aufgaben oder Projekte versuchen wir mal mehr, mal weniger erfolgreich zu strukturieren und die gemeinsame Arbeit daran zu vereinfachen. In der IT ist diese Disziplin der Teamarbeit sicherlich mit am meisten ausgeprägt. Es gibt unzählige Tools die uns bei der Koordination von Aufgaben in Projekten unterstützen. Manchmal gelingt es besser, manchmal aber eben auch schlechter. Warum ist das so? Warum kommen wir immer wieder mal an einen Punkt wo wir uns sagen ‘das hätte eigentlich besser laufen sollen’. Gerade in der IT versuchen wir dann meist mit Hilfe eines neuen Tools das Problem  künftig besser in den Griff zu bekommen – oder wenn wir richtig innovativ sind, programmieren wir uns gleich selbst ein solches Tool. Das ist übrigens auch der Grund warum es so extrem viele Projektmanagement Softwarelösungen am Softwaremarkt gibt. Continue reading “Warum Aufgabenmanagement scheitert”

Next Debian release will be incredible

The upcoming Linux distribution Debian 8.0 – code name ‘jessie’ – will become an amazing operating system.  I am testing the jessie release since one year and to me it looks promising what we can see so far.

For those who are not familiar with Linux distributions: Debian is the most used Linux destribution in the server world and most internet web servers are running on Debian. But Debian is also the base for the more known Ubuntu distribution. In fact everything you read about tips & tricks for Ubuntu is also valid for Debian and vice versa.

Unlike Ubuntu, Debian is an operating system which focuses on stability and sobriety. There is not a lot of bells and whistles. Debian uses the latest version of Gnome Shell for the desktop which is also focusing on clarity and simplicity. I personally like Gnome Shell and I recommend everyone to try it out.

systemd – speeds up booting

But one of the most impressive parts is the kernel architecture with the new “systemd” daemon. systemd is a system management which is the first process executed in user space during the Linux startup process. Therefore, systemd serves as the root of the user space’s process tree.  systemd allows more processing to be done concurrently or in parallel during system booting and reduces the computational overhead of the shell. systemd replaces the SysVinit concept and it results in an incredible increase of speed during the boot process. My own Ultrabook (Intel Core i7-3517U Ivy Bridge, 8GB RAM, 256 GB SSD) starts up in less then 10 seconds!

Altogether Debain feels very fast and compact. I like to work with this operating system and I like that debain is more clear as Ubuntu which becomes more and more confusing in its strategy (Unitiy vs Gnome, Mir vs Wayland).

Still not final….

Note that the Debian 8.0 which I am talking about is yet not final and still in a testing phase. This means you should not try it out if you are not familiar with Linux. Things can become broken and unstable. But if you can wait I guess Debian Jessie will be available in the end of this year.

 

New Version of Manik-Hot-Deploy for GlassFish and WildFly

Today I released a new Version of the Manik-Hot-Deploy Eclipse Plugin. The new version now stores the settings in a separate prefernces file stored in the project .settings/ directory. So now it is possible to share the Manik-Hot-Deploy settings with a source code repository in a team.

The Plugin can be used to deploy JEE applications in a GlassFish or JBoss/WildFly server. Manik-Hot-Deploy supports the hot deploy feature which speeds up development of JEE Web Applications.

https://github.com/rsoika/manik-hot-deploy

Debug an application in WildFly with Eclipse

You can debug a deployed applications running in WildFly with the Eclipse Debugging feature.

First you need to start WildFly in debug mode with the following command:

standalone.sh --debug --server-config=standalone.xml

Now WildFly starts in the debug mode and listens to the port 8787.

To enable debugging in your Eclipse IDE you now can add a new Debug Configuration:

wildfly_debug_eclipse

This will connect Eclipse to the WildFly Debug port.

Connection refused!

It may happen that – even if you have started glassfish in debug mode and configured all well – you got the following eclipse error message:

Failed to connect to remote VM. Connection refused.

eclipse-debug-02

In this case – it maybe can help if you add a project to the debug configuration. In the screen example above I have let the field ‘Project’ empty. It may help in some cases that you select a project there

GlassFish performance analyzing with VisualVM

This is a short overview how to do a performance analyze in GlassFish using VisualVM. When GlassFish is running and you start VisualVM it will typically connect to GlassFish. You see a local node of your GlassFish instance.

visualvm01

If GlassFish Server is not found than you need to verfy your profiler settings n GlassFish Web Console.

Now you can test the performance of your application deployed on GlassFish. Continue reading “GlassFish performance analyzing with VisualVM”

WildFly – HotDeployment

Today I extended the functionality of the manik-hot-deploy Plugin for Eclipse. The goal of this plugin is to provide an easy way for autodeployment and also hotdeployment (incremental deployment) in maven based Java Enterprise Projects.

With this Eclipse plugin you can add a configuration to your maven based JEE project to enable an autodeploy mechanism. Each time you build your maven jee project the artefacts will be automatically deployed on your application server.

Until version 1.3 only GlassFish was supported. But now I am also supporting the new WildFly Application server from Red Hat. This was a little bit tricky because in different to GlassFish WildFly did not extract (unzip) an artifact during the deployment process. But for hotdeployment you need access to the extracted web module folders. With a trick in the maven ear plugin you can create EAR artifacts with unpacked web modules. Simply add the following configuration to your ear pom.xml:

....
<build>
 <plugins>
  <plugin>
   <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-ear-plugin</artifactId>
  <version>2.6</version>
 <configuration>
 <unpackTypes>war</unpackTypes>
    </configuration>
 </plugin>

   ...

With a new option in the manik-hot-deploy plugin you can now enable the feature to autodeploy extracted versions of ear and web modules and activate the WildFly autodeployment mechanism.

Read more about mani-hot-deploy on GitHub.

 

WildFly – Performance tuning

If you run the RedHat Application Server WildFly in standalone configuraiton you can customize the Java VM options to do some performance tuning.

The VM Options

In different to GlassFish the VM Options can not be set from the WildFly Web Console. But you can change or add VM Options by changing the standalone.conf file in the /bin directory. (Note that this is not the same as the standalone.xml configuration inside the /stanalone/ folder!)

Typical values to use for a 3G RAM machine  are:

-Xmx1024m 
-Xms1024m 
-Xss128k
-XX:MaxPermSize=256m
-XX:PermSize=64m
-XX:NewRatio=2

or for a machine with 4G RAM.

-Xmx2048m 
-Xms2048m 
-Xss128k
-XX:MaxPermSize=256m
-XX:PermSize=64m
-XX:NewRatio=2

The JAVA_OPTS section in your standalone.conf file then should look like this:

...
# Specify options to pass to the Java VM.
#
if [ "x$JAVA_OPTS" = "x" ]; then
JAVA_OPTS="-Xms1024m -Xmx1024m -XX:MaxPermSize=256m -XX:NewRatio=2 -XX:PermSize=64m -Djava.net.preferIPv4Stack=true"
 JAVA_OPTS="$JAVA_OPTS -Djboss.modules.system.pkgs=$JBOSS_MODULES_SYSTEM_PKGS -Djava.awt.headless=true"
else
 echo "JAVA_OPTS already set in environment; overriding default settings with values: $JAVA_OPTS"
fi

You can verify your new settings directly in the beginning of the output when starting your WildFly

=========================================================================

 JBoss Bootstrap Environment
 JBOSS_HOME: /opt/wildfly-8.0.0.Final
 JAVA: java
 JAVA_OPTS: -server -XX:+UseCompressedOops -Xms1024m -Xmx1024m -XX:MaxPermSize=256m -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true

 

Database Pool

Also the Database Pool Configuration in WildFly is different to the settings in GlassFish. GlassFish comes with some useful default values. In WildFly you should add the following Pool Settings:

  • Min Pool Size = 5
  • Max Pools Size = 25
  • Share Prepared Statements = true
  • Statement Cache Size: 32

 

Session EJB Pooling

For some reason the pooling of stateless EJBs is disabled per default in WildFly. If you have  expensive initialization in your stateless session EJBs it is very useful to add pooling for that kind of beans. This can increase the performance of your application dramatically.

Edit the standalone.xml file in the WildFly /standalone/configuration/ directory and change the section “session-bean” like in the following example:

...
  <subsystem xmlns="urn:jboss:domain:ejb3:2.0">
            <session-bean>
                <stateless>
                    <bean-instance-pool-ref pool-name="slsb-strict-max-pool"/>
                </stateless>
                <stateful default-access-timeout="5000" cache-ref="simple" passivation-disabled-cache-ref="simple"/>
                <singleton default-access-timeout="5000"/>
            </session-bean>
            <pools>
                <bean-instance-pools>
                    <strict-max-pool name="slsb-strict-max-pool" max-pool-size="32" instance-acquisition-timeout="5" instance-acquisition-timeout-unit="MINUTES"/>
                    <strict-max-pool name="mdb-strict-max-pool" max-pool-size="20" instance-acquisition-timeout="5" instance-acquisition-timeout-unit="MINUTES"/>
                </bean-instance-pools>
            </pools>
....
.....

See also: https://community.jboss.org/message/881747

Gnome3 – system did not shutdown correctly

With the latest release of Gnome Shell (3.8) you possible can run in a situation where your system did not shutdown correctly if you select shutdown from the system menu or try to shutdown with the hardware power-off switch. In this case just check if you have the new package ‘systemd-shim’ installed. This will possible solve a missing dependency in gnome.