A EntityManagerFactory is an expensive-to-create, threadsafe object intended to be shared by all application threads. It is created once, usually on application startup.
An EntityManager is an inexpensive, non-threadsafe object that should be used once, for a single business process, a single unit of work, and then discarded. An EntityManager will not obtain a JDBC Connection or a Datasource unless it is needed, so you may safely open and close an EntityManager even if you are not sure that data access will be needed to serve a particular request.
This becomes important as soon as you are implementing some of the following patterns using request interception. To complete this picture you also have to think about database transactions. A database transaction has to be as short as possible, to reduce lock contention in the database.
Long database transactions will prevent your application from scaling to highly concurrent load. What is the scope of a unit of work? Can a single Hibernate EntityManager span several database transactions or is this a one-to-one relationship of scopes? When should you open and close a Session and how do you demarcate the database transaction boundaries? First, don't use the entitymanager-per-operation antipattern, that is, don't open and close an EntityManager for every simple database call in a single thread!
Of course, the same is true for database transactions. Database calls in an application are made using a planned sequence, they are grouped into atomic units of work. Note that this also means that auto-commit after every single SQL statement is useless in an application, this mode is intended for ad-hoc SQL console work.
In this model, a request from the client is send to the server where the EJB3 persistence layer runs , a new EntityManager is opened, and all database operations are executed in this unit of work. Once the work has been completed and the response for the client has been prepared , the persistence context is flushed and closed, as well as the entity manager object.
You would also use a single database transaction to serve the clients request. The relationship between the two is one-to-one and this model is a perfect fit for many applications. This is the default EJB3 persistence model in a Java EE environment JTA bounded, transaction-scoped persistence context ; injected or looked up entity managers share the same persistence context for a particular JTA transaction. The beauty of EJB3 is that you don't have to care about that anymore and just see data access through entity manager and demaraction of transaction scope on session beans as completely orthogonal.
The challenge is the implementation of this and other behavior outside an EJB3 container: not only has the EntityManager and resource-local transaction to be started and ended correctly, but they also have to be accessible for data access operations. The demarcation of a unit of work is ideally implemented using an interceptor that runs when a request hits the non-EJB3 container server and before the response will be send i.
We recommend to bind the EntityManager to the thread that serves the request, using a ThreadLocal variable. This allows easy access like accessing a static variable in all code that runs in this thread. Depending on the database transaction demarcation mechanism you chose, you might also keep the transaction context in a ThreadLocal variable. You can easily extend the HibernateUtil shown in the Hibernate reference documentation to implement this pattern, you don't need any external software it's in fact very trivial.
Of course, you'd have to find a way to implement an interceptor and set it up in your environment. See the Hibernate website for tips and examples. Once again, remember that your first choice is naturally an EJB3 container - preferably a light and modular one such as JBoss application server.
The entitymanager-per-request pattern is not the only useful concept you can use to design units of work. Many business processes require a whole series of interactions with the user interleaved with database accesses. In web and enterprise applications it is not acceptable for a database transaction to span a user interaction with possibly long waiting time between requests. The first screen of a dialog opens, the data seen by the user has been loaded in a particular EntityManager and resource-local transaction.
The user is free to modify the detached objects. The user clicks "Save" after 5 minutes and expects his modifications to be made persistent; he also expects that he was the only person editing this information and that no conflicting modification can occur.
We call this unit of work, from the point of view of the user, a long running application transaction. There are many ways how you can implement this in your application.
A first naive implementation might keep the EntityManager and database transaction open during user think time, with locks held in the database to prevent concurrent modification, and to guarantee isolation and atomicity.
This is of course an anti-pattern, a pessimistic approach, since lock contention would not allow the application to scale with the number of concurrent users. Clearly, we have to use several database transactions to implement the application transaction. In this case, maintaining isolation of business processes becomes the partial responsibility of the application tier. A single application transaction usually spans several database transactions. It will be atomic if only one of these database transactions the last one stores the updated data, all others simply read data e.
This is easier to implement than it might sound, especially if you use EJB3 entity manager and persistence context features:. Automatic Versioning - An entity manager can do automatic optimistic concurrency control for you, it can automatically detect if a concurrent modification occured during user think time usually by comparing version numbers or timestamps when updating the data in the final resource-local transaction.
Detached Entities - If you decide to use the already discussed entity-per-request pattern, all loaded instances will be in detached state during user think time. The entity manager allows you to merge the detached modified state and persist the modifications, the pattern is called entitymanager-per-request-with-detached-entities.
Automatic versioning is used to isolate concurrent modifications. Extended Entity Manager - The Hibernate Entity Manager may be disconnected from the underlying JDBC connection between two client calls and reconnected when a new client request occurs.
This pattern is known as entitymanager-per-application-transaction and makes even merging unnecessary. An extend persistence context is responsible to collect and retain any modification persist, merge, remove made outside a transaction. The next client call made inside an active transaction typically the last operation of a user conversation will execute all queued modifications.
Both entitymanager-per-request-with-detached-objects and entitymanager-per-application-transaction have advantages and disadvantages, we discuss them later in this chapter in the context of optimistic concurrency control.
An application may concurrently access the same persistent state in two different persistence contexts. However, an instance of a managed class is never shared between two persistence contexts.
Hence there are two different notions of identity:. Then for objects attached to a particular persistence context i. However, while the application might concurrently access the "same" persistent identity business object in two different persistence contexts, the two instances will actually be "different" JVM identity. This approach leaves Hibernate and the database to worry about concurrency; it also provides the best scalability, since guaranteeing identity in single-threaded units of work only doesn't need expensive locking or other means of synchronization.
The application never needs to synchronize on any business object, as long as it sticks to a single thread per EntityManager. This might occur even in some unexpected places, for example, if you put two detached instances into the same Set. Both might have the same database identity i. The developer has to override the equals and hashCode methods in persistent classes and implement his own notion of object equality. There is one caveat: Never use the database identifier to implement equality, use a business key, a combination of unique, usually immutable, attributes.
The database identifier will change if a transient entity is made persistent see the contract of the persist operation. If the transient instance usually together with detached instances is held in a Set , changing the hashcode breaks the contract of the Set. Attributes for good business keys don't have to be as stable as database primary keys, you only have to guarantee stability as long as the objects are in the same Set.
See the Hibernate website for a more thorough discussion of this issue. Also note that this is not a Hibernate issue, but simply how Java object identity and equality has to be implemented. Never use the anti-patterns entitymanager-per-user-session or entitymanager-per-application of course, there are rare exceptions to this rule, e. Note that some of the following issues might also appear with the recommended patterns, make sure you understand the implications before making a design decision:.
An entity manager is not thread-safe. Things which are supposed to work concurrently, like HTTP requests, session beans, or Swing workers, will cause race conditions if an EntityManager instance would be shared. If you keep your Hibernate EntityManager in your HttpSession discussed later , you should consider synchronizing access to your Http session.
Otherwise, a user that clicks reload fast enough may use the same EntityManager in two concurrently running threads. You will very likely have provisions for this case already in place, for other non-threadsafe but session-scoped objects. An exception thrown by the Entity Manager means you have to rollback your database transaction and close the EntityManager immediately discussed later in more detail.
If your EntityManager is bound to the application, you have to stop the application. Rolling back the database transaction doesn't put your business objects back into the state they were at the start of the transaction. This means the database state and the business objects do get out of sync. Usually this is not a problem, because exceptions are not recoverable and you have to start over your unit of work after rollback anyway. The persistence context caches every object that is in managed state watched and checked for dirty state by Hibernate.
This means it grows endlessly until you get an OutOfMemoryException , if you keep it open for a long time or simply load too much data. One solution for this is some kind batch processing with regular flushing of the persistence context, but you should consider using a database stored procedure if you need mass data operations. Some solutions for this problem are shown in Chapter 6, Batch processing. Keeping a persistence context open for the duration of a user session also means a high probability of stale data, which you have to know about and control appropriately.
Datatabase or system transaction boundaries are always necessary. No communication with the database can occur outside of a database transaction this seems to confuse many developers who are used to the auto-commit mode. Always use clear transaction boundaries, even for read-only operations.
Depending on your isolation level and database capabilities this might not be required but there is no downside if you always demarcate transactions explicitly. An EJB3 application can run in non-managed i. In a non-managed environment, an EntityManagerFactory is usually responsible for its own database connection pool.
The application developer has to manually set transaction boundaries, in other words, begin, commit, or rollback database transactions itself. A managed environment usually provides container-managed transactions, with the transaction assembly defined declaratively through annotations of EJB session beans, for example. Programmatic transaction demarcation is then no longer necessary, even flushing the EntityManager is done automatically. We'll now have a closer look at transaction demarcation and exception handling in both managed- and non-managed environments.
If an EJB3 persistence layer runs in a non-managed environment, database connections are usually handled by Hibernate's pooling mechanism behind the scenes. The common entity manager and transaction handling idiom looks like this:.
You don't have to flush the EntityManager explicitly - the call to commit automatically triggers the synchronization. A call to close marks the end of an EntityManager. The main implication of close is the release of resources - make sure you always close and never outside of guaranteed finally block. You will very likely never see this idiom in business code in a normal application; fatal system exceptions should always be caught at the "top".
In other words, the code that executes entity manager calls in the persistence layer and the code that handles RuntimeException and usually can only clean up and exit are in different layers. Exception handling is discussed later in this chapter. You can get an EntityTransaction through entityManager. It also provide a way to mark a transaction as rollback only, ie force the transaction to rollback.
In a JTA entity manager, entityManager. If your persistence layer runs in an application server e. Hibernate offers two strategies for this integration. With Container Managed Transactions CMT in an EJB3 container, transaction demarcation is done in session bean annotations or deployment descriptors, not programatically.
The EntityManager will automatically be flushed on transaction completion and if you have injected or lookup the EntityManager , it will be also closed automatically. If an exception occurs during the EntityManager use, transaction rollback occurs automatically if you don't catch the exception. Since EntityManager exceptions are RuntimeException s they will rollback the transaction as per the EJB specification system exception vs.
It is important to let Hibernate EntityManager define the hibernate. Remember to also set org. If you work in a CMT environment, you might also want to use the same entity manager in different parts of your code. Typically, in a non-managed environment you would use a ThreadLocal variable to hold the entity manager, but a single EJB request might execute in different threads e.
The EJB3 container takes care of the persistence context propagation for you. Either using injection or lookup, the EJB3 container will return an entity manager with the same persistence context bound to the JTA context if any, or create a new one and bind it see Section 1. In other words, all you have to do in a managed environment is to inject the EntityManager , do your data access work, and leave the rest to the container.
Transaction boundaries are set declaratively in the annotations or deployment descriptors of your session beans. The lifecycle of the entity manager and persistence context is completely managed by the container. Due to a silly limitation of the JTA spec, it is not possible for Hibernate to automatically clean up any unclosed ScrollableResults or Iterator instances returned by scroll or iterate. You must release the underlying database cursor by calling ScrollableResults.
Of course, most applications can easily avoid using scroll or iterate at all from the CMT code. Certain methods of EntityManager will not leave the persistence context in a consistent state. No exception thrown by an entity manager can be treated as recoverable. Ensure that the EntityManager will be closed by calling close in a finally block. Note that a container managed entity manager will do that for you. You just have to let the RuntimeException propagate up to the container.
The Hibernate entity manager generally raises exceptions which encapsulate the Hibernate core exception. The HibernateException , which wraps most of the errors that can occur in a Hibernate persistence layer, is an unchecked exception. Note that Hibernate might also throw other unchecked exceptions which are not a HibernateException. These are, again, not recoverable and appropriate action should be taken. By default, the SQLExceptionConverter is defined by the configured dialect; however, it is also possible to plug in a custom implementation see the javadocs for the SQLExceptionConverterFactory class for details.
ConstraintViolationException - indicates some form of integrity constraint violation. LockAcquisitionException - indicates an error acquiring a lock level necessary to perform the requested operation.
This means that the persistence context type goes beyond the transaction life cycle. We should then understand what happens to operations made outside the scope of a transaction. Some modifications operations can be executed outside a transaction, but they are queued until the persistence context join a transaction: this is the case of persist , merge , remove.
Plus if the entity manager is created outside a transaction, modifications operations persist, merge, remove are queued in the persistence context and not executed to the database. When a method of the stateful session bean involved or starting a transaction is later called, the entity manager join the transaction. All queued operation will then be executed to synchronize the persistence context.
This is perfect to implement the entitymanager-per-conversation pattern. A stateful session bean represents the conversation implementation. All intermediate conversation work will be processed in methods not involving transaction. The end of the conversation will be processed inside a JTA transaction.
Hence all queued operations will be executed to the database and commited. If you are interested in the notion of conversation inside your application, have a look at JBoss Seam. When you create an entity manager inside a transaction, the entity manager automatically join the current transaction. If the entity manager is created outside a transaction, the entity manager will queue the modification operations.
It is not legal to call entityManager. The only approach that is consistent with high concurrency and high scalability is optimistic concurrency control with versioning. Version checking uses version numbers, or timestamps, to detect conflicting updates and to prevent lost updates. Hibernate provides for three possible approaches to writing application code that uses optimistic concurrency.
The use cases we show are in the context of long application transactions but version checking also has the benefit of preventing lost updates in single database transactions.
In an implementation without much help from the persistence mechanism, each interaction with the database occurs in a new EntityManager and the developer is responsible for reloading all persistent instances from the database before manipulating them.
This approach forces the application to carry out its own version checking to ensure application transaction isolation. This approach is the least efficient in terms of database access.
It is the approach most similar to EJB2 entities:. The version property is mapped using Version , and the entity manager will automatically increment it during flush if the entity is dirty. Of course, if you are operating in a low-data-concurrency environment and don't require version checking, you may use this approach and just skip the version check.
In that case, last commit wins will be the default strategy for your long application transactions. Keep in mind that this might confuse the users of the application, as they might experience lost updates without error messages or a chance to merge conflicting changes. Clearly, manual version checking is only feasible in very trivial circumstances and not practical for most applications.
Often not only single instances, but complete graphs of modified ojects have to be checked. Hibernate offers automatic version checking with either detached instances or an extended entity manager and persistence context as the design paradigm.
A single persistence context is used for the whole application transaction. The entity manager checks instance versions at flush time, throwing an exception if concurrent modification is detected. It's up to the developer to catch and handle this exception common options are the opportunity for the user to merge his changes or to restart the business process with non-stale data. In an application-managed extended entity manager, this occurs automatically at transaction completion.
In a stateful session bean holding a container-managed extended entity manager i. This approach is the most efficient in terms of database access. The application need not concern itself with version checking or with merging detached instances, nor does it have to reload instances in every database transaction.
For those who might be concerned by the number of connections opened and closed, remember that the connection provider should be a connection pool, so there is no performance impact. The following examples show the idiom in a non-managed environment:. The foo object still knows which persistence context it was loaded in.
With getTransaction. The method getTransaction. This pattern is problematic if the persistence context is too big to be stored during user think time, and if you don't know where to store it. This is indeed recommended, as the persistence context will soon also have stale data. It is up to you where you store the extended entity manager during requests, inside an EJB3 container you simply use a stateful session bean as described above.
Don't transfer it to the web layer or even serialize it to a separate tier to store it in the HttpSession. In a non-managed, two-tiered environment the HttpSession might indeed be the right place to store it.
With this paradigm, each interaction with the data store occurs in a new persistence context. However, the same persistent instances are reused for each interaction with the database. The application manipulates the state of detached instances originally loaded in another persistence context and then merges the changes using EntityManager. Again, the entity manager will check instance versions during flush, throwing an exception if conflicting updates occured.
It is often useful for the application to react to certain events that occur inside the persistence mechanism. This allows the implementation of certain kinds of generic functionality, and extension of built-in functionality. The EJB3 specification provides two related mechanisms for this purpose. A method of the entity may be designated as a callback method to receive notification of a particular entity life cycle event. Callbacks methods are annotated by a callback annotation. You can also define an entity listener class to be used instead of the callback methods defined directly inside the entity class.
An entity listener is a stateless class with a no-arg constructor. An entity listener is defined by annotating the entity class with the EntityListeners annotation:. The same callback method or entity listener method can be annotated with more than one callback annotation. For a given entity, you cannot have two methods being annotated by the same callback annotation whether it is a callback method or an entity listener method. A callback method is a no-arg method with no return type and any arbitrary name.
Object type allowing sharing of listeners accross several entities. A callback method can raise a RuntimeException. The current transaction, if any, must be rolled back. The following callbacks are defined:. A callback method must not invoke EntityManager or Query methods! You can define several entity listeners per entity at different level of the hierarchy.
You can also define several callbacks at different level of the hierarchy. But you cannot define two listeners for the same event in the same entity or the same entity listener. EntityListeners for a given entity or superclass in the array order. You can stop the entity listeners inheritance by using the ExcludeSuperclassListeners , all superclasses EntityListeners will then be ignored.
ORM is all about object state management, which implies that object state is available in memory. However, Hibernate has some features to optimize batch processing which are discussed in the Hibernate reference guide, however, EJB3 persistence differs slightly. Note that:. There can only be a single class named in the from-clause, and it cannot have an alias this is a current Hibernate limitation and will be removed soon. Sub-queries may be used in the where-clause. The int value returned by the Query.
This may or may not correlate with the number of rows effected in the database. The returned number indicates the number of actual entities affected by the statement.
Going back to the example of joined-subclass, a delete against one of the subclasses may actually result in deletes against not just the table to which that subclass is mapped, but also the "root" table and potentially joined-subclass tables further down the inheritence hierarchy.
Both are therefore very close to SQL, but portable and independent of the database schema. Queries are case-insensitive, except for names of Java classes and properties. FOO is not org. Foo and foo. Some users find queries with uppercase keywords more readable, but we find this convention ugly when embedded in Java code.
We don't usually need to qualify the class name, since the entity name defaults to the unqualified class name Entity. So we almost always just write:. As you may have noticed you can assign aliases to classes, the as keywork is optional. An alias allows you to refer to Cat in other parts of the query. It is considered good practice to name query aliases using an initial lowercase, consistent with Java naming standards for local variables eg.
You may also assign aliases to associated entities, or even to elements of a collection of values, using a join. The inner join , left outer join constructs may be abbreviated. In addition, a "fetch" join allows associations or collections of values to be initialized along with their parent objects, using a single select. This is particularly useful in the case of a collection.
It effectively overrides the fetching options in the associations and collection mapping metadata. See the Performance chapter of the Hibernate reference guide for more information.
A fetch join does not usually need to assign an alias, because the associated objects should not be used in the where clause or any other clause. Also, the associated objects are not returned directly in the query results. Instead, they may be accessed via the parent object. The only reason we might need an alias is if we are recursively join fetching a further collection:.
Note that the fetch construct may not be used in queries called using scroll or iterate. Nor should fetch be used together with setMaxResults or setFirstResult. It is possible to create a cartesian product by join fetching more than one collection in a query as in the example above , be careful the result of this product isn't bigger than you expect.
Join fetching multiple collection roles also sometimes gives unexpected results for bag mappings, so be careful about how you formulate your queries in this case. TODO: The last statement is useless and typical developer thinking, please elaborate. The word "sometimes" should never appear in any technical documentation. If you are using property-level lazy fetching with bytecode instrumentation , it is possible to force Hibernate to fetch the lazy properties immediately in the first query using fetch all properties.
This is Hibernate specific option:. The select clause picks which objects and properties to return in the query result set. The query will select mate s of other Cat s. Actually, you may express this query more compactly as:. This is most useful when used together with select new map HQL specific feature :.
You may use arithmetic operators, concatenation, and recognized SQL functions in the select clause dpending on configured dialect, HQL specific feature :. The distinct and all keywords may be used and have the same semantics as in SQL.
Hibernate queries may name any Java class or interface in the from clause portable EJB-QL queries should only name mapped entities. The query will return instances of all persistent classes that extend that class or implement the interface. The following query would return all persistent objects:. The interface Named might be implemented by various persistent classes:.
This means that the order by clause does not correctly order the whole result set. It also means you can't call these queries using Query. The where clause allows you to narrow the list of instances returned. If no alias exists, you may refer to properties by name:.
Compound path expressions make the where clause extremely powerful. This query translates to an SQL query with a table inner join. If you were to write something like. The special property lowercase id may be used to reference the unique identifier of an object. You may also use its mapped identifer property name. Note that this keyword is specific to HQL. Properties of composite identifiers may also be used. Suppose Person has a composite identifier consisting of country and medicareNumber.
Likewise, the special property class accesses the discriminator value of an instance in the case of polymorphic persistence. A Java class name embedded in the where clause will be translated to its discriminator value. Once again, this is specific to HQL.
You may also specify properties of components or composite user types and of components of components, etc. Never try to use a path-expression that ends in a property of component type as opposed to a property of a component. For example, if store. An "any" type has the special properties id and class , allowing us to express a join in the following way where AuditLog. Any is specific to Hibernate. Notice that log. Expressions allowed in the where clause include most of the kind of things you could write in SQL:.
Any database-supported SQL scalar function like sign , trunc , rtrim , sin. SQL literals 'foo' , 69 , ' Java public static final constants eg. Likewise, is null and is not null may be used to test for null values. Booleans may be easily used in expressions by declaring HQL query substitutions in Hibernate configuration:. You may test the size of a collection with the special property size , or the special size function HQL specific feature.
For indexed collections, you may refer to the minimum and maximum indices using minindex and maxindex functions. Similarly, you may refer to the minimum and maximum elements of a collection of basic type using the minelement and maxelement functions. These are HQL specific features. The SQL functions any, some, all, exists, in are supported when passed the element or index set of a collection elements and indices functions or the result of a subquery see below.
Note that these constructs - size , elements , indices , minindex , maxindex , minelement , maxelement - may only be used in the where clause in Hibernate3. In HQL, elements of indexed collections arrays, lists, maps may be referred to by index in a where clause only :. HQL also provides the built-in index function, for elements of a one-to-many association or collection of values.
If you are not yet convinced by all this, think how much longer and less readable the following query would be in SQL:. The list returned by a query may be ordered by any property of a returned class or components:.
The optional asc or desc indicate ascending or descending order respectively. A query that returns aggregate values may be grouped by any property of a returned class or components:.
SQL functions and aggregate functions are allowed in the having and order by clauses, if supported by the underlying database eg. Note that neither the group by clause nor the order by clause may contain arithmetic expressions.
A subquery must be surrounded by parentheses often by an SQL aggregate function call. Even correlated subqueries subqueries that refer to an alias in the outer query are allowed. For subqueries with more than one expression in the select list, you can use a tuple constructor:.
Note that on some databases but not Oracle or HSQLDB , you can use tuple constructors in other contexts, for example when querying components or composite user types:. There are two good reasons you might not want to do this kind of thing: first, it is not completely portable between database platforms; second, the query is now dependent upon the ordering of properties in the mapping document. Hibernate queries can be quite powerful and complex. Here are some example queries very similar to queries that I used on a recent project.
Note that most queries you will write are much simpler than these! The following query returns the order id, number of items and total value of the order for all unpaid orders for a particular customer and given minimum total value, ordering the results by total value.
In determining the prices, it uses the current catalog. What a monster! Actually, in real life, I'm not very keen on subqueries, so my query was really more like this:. If I would have mapped the statusChanges collection as a list, instead of a set, the query would have been much simpler to write. The next query uses the MS SQL Server isNull function to return all the accounts and unpaid payments for the organization to which the current user belongs.
See Section 6. If your database supports subselects, you can place a condition upon selection size in the where clause of your query:. As this solution can't return a User with zero messages because of the inner join, the following form is also useful:. You may also express queries in the native SQL dialect of your database. Note that Hibernate3 allows you to specify handwritten SQL including stored procedures for all create, update, delete, and load operations please refer to the reference guide for more information.
This is done using the SqlResultSetMapping annotation. Now that the result set is described, we are capable of executing the native SQL query. EntityManager provides all the needed APIs. The first method is to use a SQL resultset name to do the binding, the second one uses the entity default mapping the column returned has to have the same names as the one used in the mapping.
A third one not yet supported by Hibernate entity manager , returns pure scalar results. This native query returns nights and area based on the GetNightAndArea result set. The second version is useful when your SQL query returns one entity reusing the same columns as the ones mapped in metadata. Your code doesn't need to know the difference between the two.
Hibernate EntityManager. Architecture 1. Definitions 1. EJB container environment 1. Container-managed entity manager 1. Application-managed entity manager 1. Persistence context scope 1. Persistence context propagation 1. J2SE environments 2. Setup and configuration 2. Setup 2. Configuration and bootstrapping 2. Packaging 2. Bootstrapping 2. Event listeners 2. Various 3. Working with objects 3. Entity states 3.
Making objects persistent 3. Loading an object 3. Querying objects 3. Executing queries 3. Projection 3. Scalar results 3. Bind parameters 3. Pagination 3. Externalizing named queries 3. Native queries 3. Query hints 3. Modifying persistent objects 3. Modifying detached objects 3. Automatic state detection 3. Deleting managed objects 3. Flush the persistence context 3. In a transaction 3. Outside a transaction 3. Transitive persistence 3.
Locking 4. Transactions and Concurrency 4. Entity manager and transaction scopes 4. Unit of work 4. Long units of work 4. Considering object identity 4. Common concurrency control issues 4. Database transaction demarcation 4. Non-managed environment 4.
EntityTransaction 4. Using JTA 4. Exception handling 4. Well, I must be brain-damaged, because I can't find the java source for Sun's persistence. They are open-source aren't they? Of course, I really don't have to have it, but I think it's fun to browse the source once in a while. And it helps me to debug my code sometimes. I have found the version 1.
The ejb3-persistence. The reference implementation is the one included with the Glassfish, I believe the one used in JBoss is the Hibernate implementation so you should be able to find the source code there. You are free to use the one whose license satisfies your need if you need to redistribute although I believe they are all redistributable. If all you're looking for is something to attach in eclipse, an SVN checkout should be all that you need, though I realise that this isn't exactly the answer you're looking for.
Stack Overflow for Teams — Collaborate and share knowledge with a private group. Create a free Team What is Teams? Collectives on Stack Overflow. Learn more. Asked 12 years, 11 months ago. Active 1 year, 4 months ago. Viewed 27k times. Improve this question. HaveNoDisplayName 7, gold badges 33 33 silver badges 46 46 bronze badges. Randy Stegbauer Randy Stegbauer 1, 2 2 gold badges 11 11 silver badges 25 25 bronze badges.
Add a comment.
0コメント