I would like to use the functionality of lazy="extra" with my EJB3 entity. Is this possible? The FetchType class only contains two choices: LAZY and EAGER.

No but this is a simple task to add, patch welcome.
We need to introduce a @Fetch annotation

Sure, I will contribute this as a patch.

I completed the addition of the @Fetch annotation and began to test our application. I have a patch to CVS source ready.

What I have discovered is that even with extraLazy turned on for a collection, Hibernate still does further database access when size() is called on an uninitialized Set. I would like to discuss this design and see if I could make further changes which would enhance the framework.

What we are trying to achieve with extraLazy in our application is the avoidance of further database activity (after session is closed) when an uninitialized collection is returned to the middle tier.

The middle tier (java) is a third party product dedicated to data serialization and deserialization of data between client and server.
A call to size() is needed for this serialization layer to know how many records exist, to build an array.

We want the real size of the Set to be returned. For an uninitialized Set, size() should return 0. If the Set has been initialized because of a 'fetch all' or because of a lazy init, then the size should be the number of entries in the Set.

As this time, the call to size() is throwing LazyInitializationException because we're not connected. The data has been assembled in the DAO, and should be used as-is. Hibernate assumes we always want the size() in the database, and thus an uninitialized collection can never have an uninitialized size.

I propose I make further changes to simply return actual rows in the Set for extraLazy collections. If the database record count is needed, there could be a call specific to this requirement.

Emmanuel, please give me your feedback when you have a chance. Thanks.

I would also like to propose adding extra lazy functionality to some of the other functions of a collection. This would allow more modular applications to be written with Hibernate as their persistance framework.

For example, if an application tries to use an iterator to loop through an uninitialized collection, initialization is forced even before the iterator object is created. What is desirable in our case is that we want to iterate through an empty collection. The first iterator.hasNext() call would return false and no processing would take place. We intend that the collection remain uninitialized until the client makes further function calls to ask for the data.

In our case this application is in the middle tier of the architecture, dedicated to data serialization. Because it's a java system, Hibernate is still watching the objects, but by the time they are passed in the session is closed.

One might be asking at this point just when exactly would a lazy init be desriable in our extra lazy configuration? The answer to that question is "only when we specifically ask for it".

I could see a loadAll() function being handy for finding all uninitialized extra lazy collections in an entity and loading them, with an option to go "deep". I could also see a load() function on a collection to init just one collection.

I see that the session is still required in order for Hibernate to check if a collection is lazy or not. Since our serialization framework takes over after the session is closed, we would need to remember that extraLazy is true for a collection (in AbstractPersistentCollection) after the session is closed. I believe then the call to throwLazyInitializationExceptionIfNotConnected() would be unneeded when it just preceeds if (persister.isExtraLazy()).

We are willing to make these contributions if they would be included in the framework.

lazy=extra does not mean returning wrong values, it means minimizing the amount of data retrieved from the DB at the cost of more roundtrips.
Based on this assumption:

-1 on size()
-1 on iterator.hashNext()

All of them are calls to ask for real data, not fake ones.

Emmanuel, do you have a JIRA case which I can submit the @Fetch patch to?

nope, open a new one