I've been experimenting with Hibernate Annotations, test-driving the development of some prototypes in order to evaluate the possibility of moving from XML-defined meta-data to using Annotations. I'm pretty excited about this approach, but I've ran into a problem that has me stumped, or rather, I don't see an obvious elegant solution for this particular problem.

Situation:
In my current implementation I need to be able to alternate between lazy and eager fetching for a particular entity; at times I need to be able to eagerly fetch the entity, along with all of its properties (happens by default), single-point associations and collection associations. Other times I want the latter two to be fetched lazily.

Current implementation:
Using XML-defined meta-data I have mapped this particular entity (class) twice, making use of the entity-name property. The first (default) class mapping uses default Hibernate lazy loading. The second mapping disables lazy fetching for all of the entity's single-point associations/collections, but is otherwise identical to the first. This "eager entity" is used by the associated DAO exclusively for fetching objects. This way I can tell fetch methods on the DAO to either lazily or eagerly fetch the object.

Problem:
The Annotation-based meta-data variant does not seem to offer a way to map an entity twice under different entity names.

Question:
My question is twofold:

1) Do Hibernate Annotations provide a way to multi-map a single entity, and if not what would be a viable workaround?

2) The fact that annotations do not seem to support the multi-mapping approach leads me to believe that the approach itself is bad-practice, and I've overlooked a glaringly obvious alternative. If so, what alternative approaches exist? I'm aware of Hibernate#initialize() method, but judging from the API documentation that doesn't completely fit the bill.

I'm a first-time poster on the Hibernate forums, and judging from the comment template code fragments are usally requested, but I highly doubted their relevance in this case. If need be I'd be happy to post them, though.

You can alter the fetching strategy by adding the keyword "fetch" to your joins, either in your HQL code or in your Criteria. You always specify the fetch as lazy on your annotations/mapping files, and then add "fetch" as needed.

Thank you, that is exactly what I was looking for. It just didn't seem right to me that I would need to map the same entity multiple times under a different entity name, just to accomodate alternate fetching strategies. Being able to override this behavior using HQL or Criterion/Criteria seems like an obvious approach to me now, though.

Still, mapping a class more than once could be usefull in other scenario's. In fact the reference documentation includes a (albeit rather minimalistic) paragraph explicitly devoted to multi-mapping an entity. So part of my question remains: can this be done using Hibernate Annotations?

Are you talking about inheritance mappings? Hibernate has several strategies for mapping subclasses of a parent class to one or more tables. How to map exactly the same class to many different tables, I don't know.

Specifically, I was referring to paragraph 5.3 of the Hibernate reference documentation, titled "Mapping a class more than once".
This paragraph concisely describes how to map a class twice (using entity-name), using the example of historical records.

Well, I don't know much about annotations, but the entity name, in non-annotation contexts, always defaults to the class name. And if you are using annotations, @Entity has an optional "name" parameter. Have you tried specifying it?

I have, and although I can override the default class name with the specified entity-name (as expected), this still doesn't allow me to map the same class twice using two distinct entity-names. Using XML-based mappings I can simply map the entire class twice, using distinct entity-names (see paragraph 5.3 of the reference documentation for an example). Using purely Annotation-based mappings, this does not seem to be possible. So it seems to me that the only way to accomlish multi-mapping is to either exclusively use XML-based mappings or mix XML and Annotations (not sure if the latter is possible though).

By the way, I'm still running into some problems using the approach you described earlier for overriding an entity's fetch strategy. The description in my original posting does not accurately describe the overall problem for which I am trying to find an elegant solution.

Our software solutions consists of two subsystems, a runtime environment, and a web-based management interface. These two subsystems use a lot of the same persistent business objects (and their associated mappings). For every service call the runtime environment initiates a new application session. During the lifetime of that session it is crucial that changes made to the configuration of the executing service are completely ignored by the runtime environment. So, when initializing a application session we want to make a snapshot of the associated service configuration (its object graph) and keep it in memory until the application session is eventually destroyed. For the management subsystem this is not the desired behavior.

Keeping these requirements in mind, for the runtime environment we need to eagerly fetch the entire object graph related to a service, while for the management subsystem we want the lazy loading mechanism to perform its magic. Two very distinct fetching strategies. While trying to come up with a solution for this problem I stumbled upon the multi-mapping approach (remember both subsystems share objects and their mappings), which seemed to fit the bill nicely. However using the HQL/Criteria overload approach you suggested (which I prefer), I can't seem to find an convenient way to load an entire object graph eagerly, while I am confident that it should be possible, right?

In that case I would create a subselect entity with that "snapshot", and then add to that entity, as one of its properties, the "normal" class. Both the subselect and the snapshot would share the same primary key (one-to-one association by a primary key).