Friday, September 14, 2007

Transactions (EJB3)

Transactions in EJB3 and Seam

  • ACID
  • Put all transactions in your EJBs (not in servlets)
  • Container or Bean Managed (default in Seam)
    • Container-managed-transactions (CMTs) preferred in Java EE. The Java EE container will handle comitting, rolling back, starting the transaction, etc. (no coding for the transactions).
      • 6 types of transactions to choose from (default is REQUIRED)
        • MANDATORY
        • REQUIRED
        • REQUIRES_NEW
        • SUPPORTS
        • NOT_SUPPORTED
        • NEVER
      • Example: Set this annotation before a method to use a transaction independent of an already-active transaction. Will attempt to commit in the end of the method.
        @TransactionAttribute(TransactionAttributeType.REQUIRES_NEW)
        public void addUser(User user) {
        em.persist(user);
        }
    • Bean-managed transactions (BMTs) allows a much more fine-grained control of transactions. (It is recommended to not use BMTs unless you cannot achieve the goals you are looking for using the CMT option.

Sunday, September 02, 2007

EJB3 EntityManager

Persisting Entities
  • entityManager.persist(object);
  • Can automatically generate a primary key
  • Throws IllegalArgumentException if its parameter is not an entity type
  • Throws TransactionRequiredException (Thrown by the persistence provider when a transaction is required but is not active).
  • If the Entity Manager is an extended persistent context, it is legal to call persist() outside a transaction scope.
Finding entities
  • There are 3 ways to find entities
    • find(), getReference() and createQuery()
  • The find() and getReference() methods works in the same way, they take the entity's class as a parameter and the primary key (Long).
find(Class entityClass, Object primaryKey);
getReference(Class entityClass, Object primaryKey);

Example:
Person person = null;
person = entityManager.find(Person.class, 5);
  • Two differences between find() and getReference() methods
    1. find() returns null if the entity is not found and the getReference() method throws a EntityNotFoundException.
    2. find() method initializes the state, based on the lazy-loading policies of each property, getReference() does not do that.
  • Both methods throws IllegalArgumentExceptions and they can be invoked outside the scope of transaction, but the object returned will be detached (unless entity manger is an extended persistent context).
  • With the createQuery() method it is possible to use EJB QL, HQL.
  • Summary: all the objects found using these three methods will remain managed as long as the persistent context in which you accessed them remains active.
Updating entities
  • To update an object while it is while it is managed by the persistent context is very easy. All updates on returned object (from find(), getReference(), createQuery()) will be synchronized automatically (depending on the flush mode). This is true as long as an active persistence context is still associated with the transaction. (Read more about Transaction Attribute (defaults to Required) but can be set in either ejb-jar deployment descriptor or on the EJB's bean class using @TransactionAttribute)
Merging entities
  • To merge state changes made to a detached entity back into persistent storage.
Example (person is a detached entity):
Person copy = entityManager.merge(person);
  • There are two different scenarios for the merge method, depending on if the entity manager is already managing the person entity with the same ID or not.
    • If the entity manager isn't managing the person entity with same ID, a full copy of the person parameter is made and returned from the merge() method. Now this copy will be managed by the entity manager and any additional setter methods called on it will be synchronized with the database (when flush).
    • If the entity manager is already managing the person entity with the same ID, then the contents of the person parameter is copied into this managed object instance. The merge() operation will return this managed instance and the person parameter will remain detached and unmanaged.
Removing entities
  • entityManager.remove(person);
    • person instance will not be managed any longer and will become detached
    • Associated entities may also be removed based on cascading rules
    • remove() can only be undone using persist() again
Refresh entity
  • Use entityManager.refresh(person) if you are concerned that the managed person entity is not up-to-date with the database. Will overwrite any changes of the managed entity with the one in the database.
  • Related entities may also be refreshed based on the setup cascading policy.
Contains
  • Use entityManager.contains(person) if you want to know if "person" is currently managed by the persistent context.
Clear
  • Use entityManager.clear() if you want to detach all managed entity instances from a persistence context. (Any changes made to managed entities are lost). Avoid this by calling flush() before clear().
FlushModeType
  • Flush is made automatically before any query (besides find() and getReference()) by the entity manager.
  • Change default behaviour by using Flushmode.COMMIT instead of default AUTO.
  • Using COMMIT means that changes are flushed only when the transaction commits, not before any query.
  • Set FlushType by calling the entityManager.setFlushType() method

Transactions (read more here)

Saturday, September 01, 2007

Monitoring JBoss Tool

Hyperic HQ — Systems Management Software

Have not tried this, but will for sure have a closer look when I have got time.

http://www.hyperic.com/downloads
/

Tuesday, August 28, 2007

Use JBoss loader

In file:
server\default\deploy\jbossweb-tomcat55.sar\META-INF\jboss-service.xml

Change this attribute to "true" to use the JBoss loader, this was needed for our application to be able to read resources from the classpath.

true

Saturday, August 04, 2007

Exceptions

hibernate.PersistentObjectException: detached entity passed to persist

Solution:
object = entityManager.merge(object);

Changes to "object" will be synchronized to database when flushed next time. Force flush using entitityManager.flush()

Tuesday, July 24, 2007

HQL (Hibernate Query Language)

  • Joins (SQL) (INNER, OUTER - Wikipedia)
    • inner join essentially combines the records from two tables A and B based on a given join predicate (considered default join)
    • left outer join for tables A and B always contains all records of the "left" table (A)
    • right outer join - Every record from the "right" table (B) will be in the joined table at least once.

Tuesday, January 30, 2007

JFokus

Intro: Open Source now and in the future
Simon Phipps, Sun

Talked about the benefits with Open Source. And how it is hard to gain value from taking a snapshot and adding own functionalities without giving the new source code back to the community. You would become the "Regression test slave" as Phipps expressed it. Open Source: "Earn the living by giving back".

Talked a bit about:
ODF (OpenDocument Format)
OpenOffice.org.

Software Patents, compared them to the fact that:
"American have guns because American have guns" and so do they have Patents.

Interoperability is a buzz word that Phipps did not really believed in. He did not have very hight thought of Web Services. So he wanted to introduce a new buzz word "Substitutability". It should be easy to throw out a piece of software and put in a new piece without suffering.


- Open Standards
- OpenSolaris
- OpenSPARC.net




Introduction to Java EE 5 and EJB 3

Mike Keith - Wrote "Pro EJB 3" Book.

This was mainly an introduction to EJB3s and a comparison to EJB 2.1.

Mike showed how EJB3s are simplified by using:
- Annotations
- Dependency Injection
- Simplified Web Services
- New Java Persistence API


JPA - Java Persistence API
Mike Keith

JPA was created as part of EJB3 within the JSR 220
Released May 2006 as part of Java EE 5

Key points
- javax.persistence

- Annotations makes everything much easier, but it is still possible to use XML. (@Entity, @Id etc.)

- Persistence Context - Think of a hash table where all entities are a set of "managed" entity instances.

- EntitiyManager API
-- persist() - Insert a state of an entity into the DB
-- remove(), find(), merge() etc .
The entityManager is injected into the object using it.

- Queries - Dynamic and Static
-- Query API - getResultList() etc.


- ORM

- JPA can used in Java SE as well.

Recommended tools in Eclipse: Dali JPA Tools


Secure Coding Antipatterns: Avoiding vulnerabilities

Marting Englund, Sun

Went through 6 antipatterns - things not to do while coding java thinking about security. Many examples was related to for example applets where the user have access to the source code, but how often are they used in security related solutions these days. Anyway, the 6 antipatterns were:

1. Assuming Objects are Immutable
- Attacker can change signers of a class
How to prevent: Make a copy of mutable output and input parameters (deep cloning)

2. Checks on untrusted source
- Use subclass, e.g. extend File
How to prevent: Create a new object from the untrusted source. Is it really a File object or was it a subclass.

3. Ignoring Changes to Superclasses
All changes propagate to the subclass which might open security holes.

4. Neglecting to validate inputs
- Embedded requests bypassing security checks
Requests examples: GET http://.... or Queries
Good solution: Public method that takes care of all the security (validation) and then calls the Native method.

5. Misusing Public Static variables
- Attackers can replace values whenever, the variable becomes public in the whole JVM.
Good Solution: Use private static or even better Enum.

6. Believe a constructor exception destroys the object
Solution: Use intitialized flag, check the flag in all relevant methods


Following these 6 anitpatterns should make your code more secure. Not really sure it is needed all the time though.


check out:

java.sun.com/security/seccodeguide.html (a new version to be released soon)