com.google.inject.persist Documentation Differences

This file contains all the changes in documentation in the package com.google.inject.persist as colored differences. Deletions are shown like this, and additions are shown like this.

If no deletions or additions are shown in an entry, the HTML tags will be what has changed. The new HTML tags are shown in the differences. If no documentation existed, and then some was added in a later version, this change is noted in the appropriate class pages of differences, but the change is not shown on this page. Only changes in existing text are shown here. Similarly, documentation which was inherited from another class or interface is not shown here.

Note that an HTML error in the new documentation may cause the display of other documentation changes to be presented incorrectly. For instance, failure to close a <code> tag will cause all subsequent paragraphs to be displayed differently.

Apply this filter to enable the HTTP Request unit of work and to have have guice-persist manage thethe lifecycle of active units of work. The filter automatically starts and stops the relevant PersistService upon javax.servlet.Filter.init(javax.servlet.FilterConfig) and and javax.servlet.Filter.destroy() respectively.

To be able to use the open session-in-view pattern (i.e. work per request), register thisthis filter once in your Guice {@code ServletModule}. It is is important that you register thisthis filter before any other filter.

For multiple providers, you should register this filter once per provider, inside inside a privateprivate module for each persist module installed (this must be the same private private module where the specificspecific persist module is itself installed).

Example configuration:

{@code
  public class MyModule extends ServletModule {
    public void configureServlets() {
      filter("/*").through(PersistFilter.class);

      serve("/index.html").with(MyHtmlServlet.class);
      // Etc.
    }
  }
 }

This filter is thread safe and allows you to create injectors concurrently concurrently and deploy multiplemultiple guice-persist modules within the same injector, or even even multiple injectors with persist modulesmodules withing the same JVM or web app.

This filter requires the Guice Servlet extension. @author Dhanji R. Prasanna (dhanji@gmail.com)

Install this module to add guice-persist library support for JPA persistence persistence providers. @author dhanji@gmail.com (Dhanji R. Prasanna)

Persistence provider service. Use this to manage the overall overall startup and stop of the persistencepersistence module(s).

TODO(dhanji): Integrate with Service API when appropriate. @author dhanji@gmail.com (Dhanji R. Prasanna)

Starts the underlying persistence engine and makes guice-persist ready for for use. For instance, with JPA, it creates an EntityManagerFactory and may may open connection pools. This method must bebe called by your code prior to to using any guice-persist or JPA artifacts. If already started, calling this method does nothing, if already stopped, it also does does nothing.

Stops the underlying persistence engine. For instance, with JPA, it it closes the {@codecode EntityManagerFactory}. If already stopped, calling this this method does nothing. If not yetyet started, it also does nothing.

Any method or class marked with this annotation will be considered for transactionality. ConsultConsult the documentation on https://github.com/google/guice/wiki/GuicePersist for detailed detailed semantics. Marking a method {@code @Transactional} will start a new transaction before the method executesmethod executes and commit it after the method returns.

If the method throws an exception, the transaction will be rolled back unless youyou have specifically requested not to in the .ignore() clause.

Similarly, the set of exceptions that will trigger a rollback can be defined in in the .rollbackOn() clause. By default, only unchecked exceptions trigger a a rollback. @author Dhanji R. Prasanna (dhanji@gmail.com)

This interface is used to gain manual control over the unit of work. This is mostly to do do work inin non-request, non-transactional threads. Or where more fine-grained control over the unit unit of workwork is required. Starting and ending a unit of work directly corresponds to opening and and closing aa {@code Session}, {@code EntityManager} or {@code ObjectContainer} respectively.

The The Unit of Work referred to by UnitOfWork will always be local to the calling thread. BeBe careful to to end() in a finally block. Neither JPA, nor Hibernate supports threadsafe sessionssessions (reasoning reasoning behind thread-locality of Unit of Work semantics).

• Using UnitOfWork with the PersistFilter inside a request is not recommended.
• Using UnitOfWork with session-per-txn strategy is not terribly clever either.
• Using UnitOfWork with session-per-request strategy but *outside* a request (i.e. in a background or bootstrap thread) is probably a good use case.

@author Dhanji R. Prasanna (dhanji@gmail com)

Starts a Unit Of Work. Underneath, causes a session to the data layer to be opened. If there isthere is already one open, the invocation will do nothing. In this way, you can define arbitrary units-of-work that nest within one another safely.

Transaction semantics are not affected.

Declares an end to the current Unit of Work. Underneath, causes any open session to the data layer to close. If there is no Unit of work open, then the call returns silently. You can safely invoke end() repeatedly.

Transaction semantics are not affected.