import com.tcs.spring.Printador;
import org.springframework.context.support.ClassPathXmlApplicationContext;

public class Exemplo {

    public static void main(String[] args) {
        new Exemplo().start();
    }

    public void start() {
        ClassPathXmlApplicationContext ctx = new ClassPathXmlApplicationContext("applicationContext.xml");
        Printador printador = (Printador) ctx.getBean("printador");
        printador.printar();
    }
}

package com.tcs.spring;

public class Printador {
    private String mensagem;

    public void setMensagem(String msg) {
        mensagem = msg;
    }

    public void printar() {
        System.out.println(mensagem);
    };
}

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE beans PUBLIC "-//SPRING//DTD BEAN//EN" "http://www.springframework.org/dtd/spring-beans.dtd">
<beans>
    <bean id="printador" class="com.tcs.spring.Printador">
        <property name="mensagem" value="Menssagem vinda do XML de maneira magica!"/>
    </bean>
</beans>

I call it my billion-dollar mistake. It was the invention of the null reference in 1965. At that time, I was designing the first comprehensive type system for references in an object oriented language (ALGOL W). My goal was to ensure that all use of references should be absolutely safe, with checking performed automatically by the compiler. But I couldn't resist the temptation to put in a null reference, simply because it was so easy to implement. This has led to innumerable errors, vulnerabilities, and system crashes, which have probably caused a billion dollars of pain and damage in the last forty years.

Watch out for Unsynchronized Entities

One thing to watch out for when updating entities like this, is that the EntityManager may contain outdated entities after the query has executed. This could be the case if your JPA provider uses a cache (such as Hibernate’s second level cache), or if there are changes that are pending to be flushed. As a result, the state of the entities in the EntityManager may not be accurate. This would be the case if an entity affected by the update query is referenced in the EntityManager. One may wonder why the EntityManager is not just cleared after executing the query to avoid this inconsistency, but the reason for this is that there might be changes that have not yet been flushed, that would then be lost. However, you do get the option of configuring this by setting the clearAutomatically attribute of the @Modifying annotation to true.

Unlike the BULK INSERT statement, which holds a less restrictive Bulk Update lock, INSERT INTO...SELECT with the TABLOCK hint holds an exclusive (X) lock on the table. This means that you cannot insert rows using parallel insert operations.

"At some point, you have to jump out of the plane under the assumption that you can get the parachute sewn together in time to deploy it."

~ Jack Rickard

My father worked in this project at IBM.