I am using a custom date class, which is aware of two timezones, the user's and the database's (for an app which has users around the world). These timezones are maintained in the UserDomain class/table, which is not referenced by any of the data classes.

When loading a date from the database, I need to be able to pass these two timezones into my custom type. At the moment, I'm using a global ThreadLocal to get a handle to my container manager, but this is inelegant. I'd rather configure my session, session factory or session provider and access the data in my UserType using that configuration.

So my question is: is it possible to get the session (or any other "configuration" data) during the loading of a UserType? ParameterizedType works for data known at compile time, but I'm dealing with data not known until runtime (specifically, when the user logs in).

Noone has any thoughts on this? Is it impossible to access "external" information when instantiating a user type?

use a threadlocal - serves the purpose brilliantly imo.

Hi,

I have the same situation and a ThreadLocal doesn't help me as I can use different SessionFactories with in the same thread and each SessionFactory can have different settings.

Is there any other way to configure a SessionFactory so that is passes some configuration settings to a UserType?

Maybe there are some other workarounds?

Thanks,
Joern

i'm sorry but why cant you use a threadlocal ?

Just key it per SF or just set the value before using it and clear it out afterwards - you cant be creating a multiple SF in the same thread.

Or simply define your usertype in a <typedef> and have one hbm.xml with that typedef in per SF and specify the custom part in there.

max, thanks for your response.

Let me describe my problem a bit more in detail:

My Hibernate SessionFactory is stored in an ApplicationContext and each ApplicationContext has its own Hibernate SessionFactory. An application can use many ApplicationContexts, i.e. I can use more than one SessionFactory in one thread.

What I want to achieve is that the entites that are retrieved by a session should be aware of the ApplicationContext they belong to.
Whenever an object is retrieved out of the DB I want to set its ApplicationContext in the object. Pleae note that the ApplicationContext doesn't get stored in the DB.

So my idea was, to attach to each SessionFactory its ApplicationContext and every time an object is retrieved I use an UserType (or alternatively an Interceptor) to set the SessionFactory's AppicationContext to the created entity.

But it seems that this doesn't work for two reasons:
1. The Interceptor or UserType isn't aware of the Session or SessioFactory that calls it.
2. You cannot attach objects to a SessionFactory.

Is there any other solution to my problem?

Thanks,
Jörn

I'm still not too thrilled about using ThreadLocals, but they are working for me. If your ApplicationContexts are shared between threads, then you don't need a ThreadLocal, a static Map would work better: if they're not, then a Map in a ThreadLocal does the trick.

Now that my main project has finished its migration to Spring, I'd say that the best way to do this (imo) would be to have instances of the user type be retrieved from Spring, so that it can work its dependency-inject magic on them. I haven't changed the original custom date class that prompted this thread, but some newer user types that I've written have used Spring to create (empty) instances of the appropriate entity class, and Spring knows about the objects that would otherwise be stored in ThreadLocals. It's working well, and I get to hide all the global/threadlocal variables inside Spring configurations.

If you're not using Spring, then any equivalent implementation of the factory pattern works just as well. You configure your factory in (e.g.) a web filter, or at thread startup-time, and have your user type's nullSafeGet method request new instance from the facory in a thread-agnostic way.

I dont understand why you are using user types to set this up instead of using a much simpler Interceptor to set the applicationcontext in the .instantiate method.

As long as you configure an Interceptor per SF then its all fine and dandy.

I didn't do it because I didn't know that interceptors had an instantiate method. That's what I was looking for when I first asked the question. I'll play around with that, it looks ideal for what I need.