Skip to main content

Home/ SoftwareEngineering/ Group items tagged EntityManager

Rss Feed Group items tagged

kuni katsuya

jpa - When to use EntityManager.find() vs EntityManager.getReference() - Stack Overflow - 0 views

  • When to use EntityManager.find() vs EntityManager.getReference()
  • use getReference method when i do not need to access database state
  • getReference returns a proxy object which uses a powerful feature called
  • ...1 more annotation...
  • automatic dirty checking
  •  
    "When to use EntityManager.find() vs EntityManager.getReference()"
kuni katsuya

Java Persistence/Runtime - Wikibooks, open books for an open world - 0 views

  • In JEE the EntityManager or EntityManagerFactory can
  • injected into a SessionBean
  • A managed EntityManager should never be closed, and integrates with JTA transactions
  • ...3 more annotations...
  • Example of injecting an EntityManager and EntityManagerFactory in a SessionBean
  • @Stateless
  • @PersistenceContext(unitName="acme") private EntityManager entityManager;
kuni katsuya

java - what is difference between EntityManager.find() and EntityManger.getReference()?... - 0 views

  • what is difference between EntityManager.find() and EntityManger.getReference()?
  • find()
  • return an initialized instance of your object
  • ...6 more annotations...
  • If it is not already loaded in the EntityManager, it is retrieved from the database
  • getReference()
  • is allowed to return a proxy instread of an initialized instance, if the entity has not been loaded in the EntityManager before
  • In this proxy,
  • only the primary key attribute is initialized
  • Proxies can be created without hitting the database
kuni katsuya

Shiro User - Shiro in CDI/JPA2/JSF2 project - 1 views

  • CDI, JPA2 and JSF2
  • Apache Shiro
  • JpaRealm
  • ...10 more annotations...
  • Entity Beans in combination with an EntityManager
  • use CDI to inject the EntityManager into my JpaRealm
  • JpaRealm is not container managed but is instantiated by Shiro
  • delegate your JpaRealm into @Stateless EJB, which can @Inject EntityManager
  • JpaRealm
  • @PersistenceContext   private EntityManager entityManager;
  • EnvironmentLoaderListener
  • found the cause
  • Instead of configuring the ShiroFilter in my web.xml I had the IniShiroFilter configured. The IniShiroFilter creates a new SecurityManager from the ini file. This new SecurityManager didn't know about the realm I've added in my EnvironmentLoader, so it didn't have any realms.
  • I replaced it with the ShiroFilter in my web.xml and all seems to be working now with my CdiEnvironmentLoaderListener.
kuni katsuya

How to get EntityManager in a Apache Shiro Realm | OpenShift by Red Hat - 0 views

kuni katsuya

Java Persistence/Transactions - Wikibooks, open books for an open world - 0 views

  • JTA transactions are
  • implicitly defined through SessionBean usage/methods. In a SessionBean normally each SessionBean method invocation defines a JTA transaction.
  • JTA Transactions
  • ...10 more annotations...
  • In JEE managed mode, such as an EntityManager injected into a SessionBean, the EntityManager reference, represents a new persistence context for each transaction. This means objects read in one transaction become detached after the end of the transaction, and should no longer be used, or need to be merged into the next transaction. In managed mode, you never create or close an EntityManager.
  • Transactions
  • operations that are committed or rolled back as a single unit
  • JPA provides two mechanisms for transactions
  • JTA (Java Transaction API
  • EntityTransaction
  • all changes made to all persistent objects in the persistence context are part of the transaction.
  • Nested Transactions
  • do not support nested transactions
  • JPA and JTA
kuni katsuya

Lean service architectures with Java EE 6 - JavaWorld - 0 views

  • DAOs aren't dead, but they cannot be considered as a general best practice any more. They should be created in a bottom-up, rather than a top-down, fashion. If you discover data-access code duplication in your service layer, just factor it out to a dedicated DAO and reuse it. Otherwise it is just fine to delegate to an EntityManager from a service. The enforcement of an empty DAO layer is even more harmful, because it requires you to write dumb code for even simple use cases. The more code is produced, the more time you must spend to write tests and to maintain it.
  • With JDK 1.5 and the advent of generics, it is possible to build and deploy a generic, convenient, and typesafe DAO once and reuse it from variety of services
  •  
    DAOs aren't dead, but they cannot be considered as a general best practice any more. They should be created in a bottom-up, rather than a top-down, fashion. If you discover data-access code duplication in your service layer, just factor it out to a dedicated DAO and reuse it. Otherwise it is just fine to delegate to an EntityManager from a service. The enforcement of an empty DAO layer is even more harmful, because it requires you to write dumb code for even simple use cases. The more code is produced, the more time you must spend to write tests and to maintain it.
kuni katsuya

EntityManager (Java EE 6 ) - 0 views

  • createNamedQuery(java.lang.String name)
  • Java Persistence query language or in native SQL
kuni katsuya

JPA implementation patterns: Retrieving entities | Xebia Blog - 0 views

  • JPA implementation patterns: Retrieving entities
  • two ways to retrieve an entity with JPA:
  • EntityManager.find
  • ...2 more annotations...
  • Query object that can then be executed to return a list of entities or a single entity.
  • Keeping the query and the code that sets these parameters together makes them both easier to understand
kuni katsuya

Why you should never use getSingleResult() in JPA | Sysout.be - 0 views

  • The only use for getSingleResult() is when we are
  • executing a scalar (count, sum, avg) query
  • query wich will
  • ...8 more annotations...
  • alway
  • return a row
  • 3 ways to do this
  • EntityManger.find()
  • returns a typed instance of the entity when it is found, null when it is not found
  • But what if the row isn’t in the database (anymore)?
  • We get an unchecked exception: NoResultException
  • We never know for sure what we can expect from our database, so throwing an unchecked exception seems the wrong choice for this use-case
    • kuni katsuya
       
      thinking defensively, in a pathological scenario, the data and/or schema of the database could be corrupt eg. using a named query that should return a single entity based on a unique constraint of a table: - what if the unique constraint was implemented incorrectly in the ddl? (too relaxed or too strict) - what if the data became inconsistent as a result of some external process? => should always code defensively, especially at integration points to anything external to the jvm 
kuni katsuya

The JPA 2 Enhancements Every Java Developer Should Know - Developer.com - 0 views

  • JPA 2 Enhancements Every Java Developer Should Know
  • JPA 2 also introduced a second layer of cache, which is shared across various persistence contexts and can be accessed using the EntityManagerFactory
  • Cache cache = emf.getCache();
  • ...4 more annotations...
  • Enhancements in EntityManagerFactory Interface
  • Enhancements in EntityManager Interface
  • detach
  • getEntityManagerFactory
kuni katsuya

Pro JPA 2: Mastering the Java™ Persistence API > Advanced Topics > SQL Querie... - 0 views

  • queries are also known as native queries
  • SQL Queries
  • reasons why a developer using JP QL might want to integrate SQL queries into their application
  • ...32 more annotations...
  • JPA 2.0, still contains only a subset of the features supported by many database vendors
  • features not supported in JP QL.
  • performance required by an application is to replace the JP QL query with a hand-optimized SQL version. This may be a simple restructuring of the query that the persistence provider was generating, or it may be a vendor-specific version that leverages query hints and features specific to a particular database.
  • recommend avoiding SQL initially if possible and then introducing it only when necessary
  • benefits of SQL query support is that it uses the same Query interface used for JP QL queries. With some small exceptions that will be described later, all the Query interface operations discussed in previous chapters apply equally to both JP QL and SQL queries.
  • keep application code consistent because it needs to concern itself only with the EntityManager and Query interfaces.
  • An unfortunate result of adding the TypedQuery interface in JPA 2.0 is that the createNativeQuery() method was already defined in JPA 1.0 to accept a SQL string and a result class and return an untyped Query interface
  • consequence is that when the createNativeQuery() method is called with a result class argument one might mistakenly think it will produce a TypedQuery, like createQuery() and createNamedQuery() do when a result class is passed in.
  • @NamedNativeQuery
  • resultClass=Employee.class
  • The fact that the named query was defined using SQL instead of JP QL is not important to the caller
  • SQL Result Set Mapping
  • JPA provides SQL result set mappings to handle these scenarios
  • A SQL result set mapping is defined using the @SqlResultSetMapping annotation. It may be placed on an entity class and consists of a name (unique within the persistence unit) and one or more entity and column mappings.
  • entities=@EntityResult(entityClass=Employee.class)
  • @SqlResultSetMapping
  • Multiple Result Mappings
  • A query may return more than one entity at a time
  • The SQL result set mapping to return both the Employee and Address entities out of this query
  • emp_id, name, salary, manager_id, dept_id
  • address_id, id, street, city, state, zip
  • order in which the entities are listed is not important
  • ntities={@EntityResult(entityClass=Employee.class), @EntityResult(entityClass=Address.class)}
  • expected result type and therefore received an instance of TypedQuery that is bound to the expected type. By qualifying the result type in this way, the getResultList() and getSingleResult() methods return the correct types without the need for casting.
  • Defining a Class for Use in a Constructor Expression
  • public EmpMenu(String employeeName, String departmentName)
  • List<EmpMenu>
  • NEW example.EmpMenu(" + "e.name, e.department.name)
  • EmpMenu.class
  • createNamedQuery() can return a TypedQuery whereas the createNativeQuery() method returns an untyped Query
  • List<Employee>
  • createNamedQuery("orgStructureReportingTo", Employee.class)
kuni katsuya

15 Tips on JPA Rich Domain Modelling - Thinking In Objects - Not Mappings [For Greenfie... - 0 views

  • [For Greenfields]
  • Try to identify concepts and abstractions from the target domain. Use them as candidates for entities.
  • Do not obfuscate them with additional technical naming conventions like XYZEntity or "BOs".
  • ...10 more annotations...
  • Write unit tests
  • without involving the EntityManager
  • - Thinking In Objects
  • JPA Rich Domain Modelling
    • kuni katsuya
       
      strategy to use when less or unconstrained by legacy db schema baggage. ie. the *proper* and *ideal* way to model domain classes... using oo, not dumb structs!  :)
  • Build objects, not structs
  • Think about builders
  • Let the tool (JPA-provider) generate the DDL
    • kuni katsuya
       
      generated ddl can be optimized by hand if required
    • kuni katsuya
       
      eg. see step 12 below
  • Provide a lean facade/service layer
  • only contain crosscutting concerns
1 - 13 of 13
Showing 20 items per page