Rafael de Sousa

Hi all,

Ran through the JPA exam yesterday and got 93% score.

The study strategy was pretty simple. Four months, one hour per day, monday to friday as follows:

* Read Pro Jpa 2 Mastering the java persistence API (chapters 1-11).
* Took Enthuware JPA mock.
* Review the wrong answered questions from mock.

As a tip, there was no surprises, all exam topics was covered by the mock, so make sure you're actually understanding the questions.

Cheers!!!

Hi Sudhanshu Mishra,

Let me add some words that may help you,

Why is it important to consider the directionality?

The main point of a ORM is to reflect the database model. Sometimes, changing the directionality of an entity relationship requires a different database model. Besides that, it's important to know how annotations may be used together, for example, an unidirectional property annotated with @OneToMany may define the @JoinTable annotation to override the defaults.

I understand that an entity having a reference to other entity accounts for a direction, but is it all to it?

Pretty much. But make sure you can spot the directionality for a given model, e.g.

@Entity public class Parent(){ @OneToMany private List<Child> children; } @Entity public class Child(){ @ManyToOne @JoinColumn private Parent parent; }

Although it seems to be a bidirectional relationship, it's not.

Do my mapping annotations have any thing to do with directionality, or they simply indicate the cardinality?

Your mappings indicate both implicitly or explicitly, but there's nothing special about those concepts. While directionality it's about how entities reach each other, cardinality defines if an entity has one or more instances of a referenced entity.

Cheers!

Hi Shikha bajpai,

Try this,
@Column(name = "PAYLOAD_YOGTEST", columnDefinition="XMLType") //nullable = true, length = 255) private String payload;

if you still haven't lucky, try to convert the column
@ColumnTransformer(read = "to_clob(data)", write = "?") @Column(name = "PAYLOAD_YOGTEST", columnDefinition="XMLType") //nullable = true, length = 255) private String payload;

Cheers!

Hi Sudhanshu Mishra,

Although you created a valid generator, you still need to override the default generation strategy, as follows:

@GeneratedValue(generator="Emp_gen", strategy=GenerationType.TABLE)

There's no need for pushing anyone for answers, alright?!

Hi Cesar Koot,

I believe it says, when a locked entity A has a collection of entity B, entity A can't add or remove any B(e.g. A.getCollectionB().add(new B())), but you can change any B state, like B.name or B.email (e.g. A.getCollectionB().get(0).setName("New B Name")) if B it's not explicitly locked.

Hi Levent Erguder,

The mapping doesn't act like a restriction, instead it just limit the number of objects an source entity might refer to the target entity. The following is a snipped from Pro JPA 2

As it turns out, one-to-one mappings are almost the same as many-to-one mappings except that
only one instance of the source entity can refer to the same target entity instance.

Although you can set the "unique" attribute from @JoinColumn to true, which creates a column with uniqueness, achieving the desired behavior:

@Entity public class Employee { //... @OneToOne @JoinColumn(name="parkingSpace", unique = true) private ParkingSpace parkingSpace; //... }

Hi Daniel,

Since you're using a Stateless to find and update the entity instance, here goes some points:

1 - When you first call a method on Stateless session bean to find the specific Employee(10001A) for user1, the container starts a new transaction, then you set pessimistic lock and the search method finishes.
2 - When the method finishes, the container commits the transaction, releasing the previously lock on the managed entity.
3 - At this point, the user1 is changing a detached Employee(10001A) entity

The steps above fits to you scenario? Can you post your code that performs the update on Employee entity?

Hi Daniel,

Are you tryin' to block two or more concurrent entity update calls? What is the expected behavior when a user tries to update an entity that it's already been updated by other user? The user should wait until the other finishes the entity update or an exception should be thrown in order to inform that entity it's been updated by someone else?

I tried the following to fire an javax.persistence.PessimisticLockException:
//Creates an entity manager factory EntityManagerFactory emf = Persistence.createEntityManagerFactory("PersistenceUnit"); EntityManager em1 = emf.createEntityManager(); //Starts a transaction and associates a persistence context on it em1.getTransaction().begin(); EntityManager em2 = emf.createEntityManager(); //Starts a transaction and associates a persistence context on it em2.getTransaction().begin(); //Managed entity from the first entity manager persistence context Employee employeeFromEntityManager1 = em1.find(Employee.class, 1); employeeFromEntityManager1.setName("Employee 1"); //Managed entity from the second entity manager persistence context Employee employeeFromEntityManager2 = em2.find(Employee.class, 1, LockModeType.PESSIMISTIC_WRITE); employeeFromEntityManager2.setName("Employee 2"); //Commits the transaction and updates de version of the managed employee entity em1.getTransaction().commit(); em1.close(); //Should throw the javax.persistence.PessimisticLockException here em2.getTransaction().commit(); em2.close(); emf.close();

But since pessimistic locks are synchronous, when the code execution reaches the line 20, it waits until the transaction created at line 9 commits and release the lock. Thus the exception it's never thrown. If we replace the locking mode at line 23 to:

Employee employeeFromEntityManager2 = em2.find(Employee.class, 1, LockModeType.OPTIMISTIC);

An OptimisticLockException would be thrown at line 23 since the entity version has changed, as you already assumed.

Since your Employee entity doesn't have a compound primary key, you don't need to set all those parameters on Address just to target your employee. Try something like this:

@Entity @Cacheable(false) @Table(name="address") class Address{ @Id @SequenceGenerator(name="add_SEQ", allocationSize=25) @GeneratedValue(strategy=GenerationType.SEQUENCE, generator="add_SEQ") @Column(name="address_id") private int address_id; @ManyToOne(fetch = FetchType.EAGER) @JoinColumns( { @JoinColumn(name = "e_id")}) private Employee emp; // all getters and setters }

Some highlights you should consider when refactoring your code:

* insertable and updatable , when setted to false, are meant to inform the persistence provider that whenever an insert and/or update operation are fired on Address entity it should not include the mapping on the generated query.
* referencedColumnName is used to specify a column name which the foreign key targets. When not present, the default behavior is target's primary key.

Just remember, the Entity who holds the "mappedBy" is the target(Address), the other one the source Entity(Employee).

My advice, take them in this order:
1) OCEEJB, check ScbcdLinks
2) OCEJPA, check ScbcdLinks
3) OCEWSD, check ScdjwsLinks

Aggreed. Currently I'm on OCEJPA, the exam is scheduled to february (=

If an exception rises when you call getTransaction() method on the entity manager, you should check if you are using container manager transaction which is default when @TransactionManagement(TransactionManagementType.BEAN) is not explicitly declared.

To fire native bulk queries, try something like this, extracted from Apress - Pro JPA 2:
String INSERT_SQL = "INSERT INTO message_log (id, message, log_dttm) VALUES(id_seq.nextval, ?, SYSDATE)"; em.createNativeQuery(INSERT_SQL).setParameter(1, message).executeUpdate();