[hibernate-dev] Integrator and retrieving objects

Adam Warski adam at warski.org
Wed Apr 27 04:48:28 EDT 2011 

The AuditReader is stateful on the other hand - apart from the Session and Envers config (which could be looked up each time), it contains a first-level cache for already resolved historical objects.

Adam

On Apr 26, 2011, at 8:04 PM, Emmanuel Bernard wrote:

> To clarify, FullTextSession is stateless besides holding a pointer to the Session(Implementor). so we would be fine by creating a new FullTextSession object every time as() is called.
> 
> On 26 avr. 2011, at 19:47, Sanne Grinovero wrote:
> 
>> 2011/4/26 Steve Ebersole <steve at hibernate.org>:
>>> as(...) is on Session though.  What I am talking about is what happens when
>>> they *somehow* get a normal Session and call session.as(
>>> FullTextSession.class ) ?
>>> 
>>> e.g.
>>> 
>>> fullTextSession.getSessionFactory()
>>>       .openSession()
>>>       .as( FullTextSession.class );
>>> 
>>> Now what?
>> 
>> Let's assume we also have a service called "SessionAsHandler", which
>> contains a map of factories, where the key is the target class (like
>> FullTextSession.class )
>> The "as" implementation could look into the SessionAsHandler, perform then
>> 
>> get(FullTextSession.class).create( this );
>> 
>> where:
>> - this is the current SessionImplementor
>> - the return type is a FullTextSession instance
>> 
>> And when the SearchService is created, it configures this additional
>> service as well to handle the new type.
>> 
>>> 
>>> I guess this really gets to the intent of as(...).
>>> 
>>> Like I can see the usefulness of "light binding" the notions of a Session
>>> and a FullTextSession (not so sure wrt AuditReader, I'd have to understand
>>> the relation there a little better) such that the following is valid:
>>> 
>>> normalHibernateSessionFactory.openSession()
>>>       .as( FullTextSession.class )
>>>       .<handle yo search biz>()
>>> 
>>> But there are a lot of implications there.  Like we need to be able to make
>>> the SessionFactory aware of the other "sub factories" and track the "sub
>>> sessions" per Session (lazily!).
>> 
>> I'm not sure I follow here about tracking and lazily. Why should you
>> track the "sub sessions"? In case of Search, the
>> FullTextSession.close() will close it's own resources and close the
>> underlying Session as well; I think it's enough for the SessionFactory
>> to track the standard Session and doesn't need to worry about more
>> resources.
>> 
>>> 
>>> Heck, I would *love* to see:
>>> normalHibernateSessionFactory.openSession()
>>>       .as( EntityManager.class )
>>>       ...
>> 
>> but then the EntityManager would be able to behave according to JPA
>> spec? I'm referring for example to the different kind of
>> eventlisteners needed, as Emmanuel mentioned at the meeting today.
>> Still this example is so cool, it could be worthwhile to reconsider
>> some of the meeting thoughts.
>> Would you expect the EntityManager to be closed if I closed the
>> Session? And flush, other operations? according to which spec shall it
>> behave?
>> 
>> Cheers,
>> Sanne
>> 
>> 
>>> On 04/26/2011 01:31 AM, Sanne Grinovero wrote:
>>>> 
>>>> 2011/4/25 Steve Ebersole<steve at hibernate.org>:
>>>>> 
>>>>> Just to circle back to this (because my memory is so short)..
>>>>> 
>>>>> What did we ever decide about this, especially in regards to the *how*?
>>>>> 
>>>>> As and example, lets look at Search.  Search wraps Session in a
>>>>> FullTextSession.  Search would register some handler with the
>>>>> SessionFactory that says it knows how to handle Session.as(
>>>>> FullTextSession.class ) calls.  But what exactly is this handler going
>>>>> to do?  Unless Search maintains some global Session instance ->
>>>>> FullTextSession instance...  Or are you thinking the registration
>>>>> happens per-Session?
>>>> 
>>>> The entry points for Search are two:
>>>> - the session *EventListener(s) (only one instance, but listening to
>>>> multiple types of events)
>>>> - the FullTextSession
>>>> 
>>>> A FullTextSession needs a reference to the current session, and a
>>>> reference to the SearchFactoryImplementor, which is the heavy-weight
>>>> global component, similar to a SessionFactory.
>>>> 
>>>> Currently a FullTextSession implements Session and is created from the
>>>> Session it wraps using a static helper which searches for it's own
>>>> PostInsertEventListener in the Session itself, from which it takes a
>>>> reference to the needed  SearchFactoryImplementor.
>>>> 
>>>> I would be a nice improvement if the "as( FullTextSession.class )"
>>>> implementation could retrieve the SearchFactoryImplementor from the
>>>> ServiceRegistry instead.
>>>> 
>>>> In pseudo code, the "as" implementation for search would look like
>>>> something as:
>>>> 
>>>> FullTextSession createFullTextSession() {
>>>>   return new FullTextSession( Session current, serviceRegistry.get(
>>>> SearchFactoryImplementor.class ) );
>>>> }
>>>> 
>>>> (or even simpler if SessionImplementor makes it possible to retrieve
>>>> services )
>>>> 
>>>> Regards,
>>>> Sanne
>>>> 
>>>>> 
>>>>> 
>>>>> On 04/06/2011 09:28 AM, Emmanuel Bernard wrote:
>>>>>> 
>>>>>> yes as is indeed better.
>>>>>> 
>>>>>> On 6 avr. 2011, at 13:29, Steve Ebersole wrote:
>>>>>> 
>>>>>>> A phrase I see a lot here is "as":
>>>>>>> 
>>>>>>> session.as( AuditReader.class ).someEnversSpecificMethod()
>>>>>>> 
>>>>>>> or
>>>>>>> 
>>>>>>> session.as( FullTextSession.class )...
>>>>>>> 
>>>>>>> 
>>>>>>> On 04/06/2011 06:26 AM, Adam Warski wrote:
>>>>>>>> 
>>>>>>>> On Apr 6, 2011, at 1:20 PM, Steve Ebersole wrote:
>>>>>>>> 
>>>>>>>>> The phrase 'unwrap' might be a bit misleading there because you may
>>>>>>>>> not be dealing with wrapped objects.  But the idea itself is still solid I
>>>>>>>>> believe.  Think of it more as a multi-directional cast
>>>>>>>> 
>>>>>>>> Right, the idea sounds good; so it would be something like a
>>>>>>>> per-session service? :)
>>>>>>>> Envers could use it as well, right now just as search has
>>>>>>>> Search.getFullTextSession, envers has AuditReaderFactory.getFor
>>>>>>>> So we could have session.service(AuditReader.class /
>>>>>>>> FullTextSession.class).
>>>>>>>> 
>>>>>>>> Adam
>>>>>>>> 
>>>>>>>>> On Apr 6, 2011 6:15 AM, "Adam Warski"<adam at warski.org>     wrote:
>>>>>>>>>> 
>>>>>>>>>>> FullTextSession ftSession = session.unwrap(FullTextSession.class);
>>>>>>>>>>> //the current approach is via some static helper method
>>>>>>>>>>> //FullTextSession ftSession = Search.getFullTextSession(session);
>>>>>>>>>>> 
>>>>>>>>>>> That would mean that the integration point between HSearch and
>>>>>>>>>>> Hibernate would have an unwrap method and Hibernate would delegate the
>>>>>>>>>>> unwrap calls to each integrator until a non null object is returned.
>>>>>>>>>>> 
>>>>>>>>>>> It's just a thought, WDYT?
>>>>>>>>>> 
>>>>>>>>>> But while EntityManager wraps a Session object, a Session doesn't
>>>>>>>>>> wrap a FullTextSession, but the other way round, no?
>>>>>>>>>> 
>>>>>>>>>> --
>>>>>>>>>> Adam Warski
>>>>>>>>>> http://www.warski.org
>>>>>>>>>> http://www.softwaremill.eu
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> _______________________________________________
>>>>>>>>>> hibernate-dev mailing list
>>>>>>>>>> hibernate-dev at lists.jboss.org
>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>>>>>> 
>>>>>>> 
>>>>>>> --
>>>>>>> Steve Ebersole<steve at hibernate.org>
>>>>>>> http://hibernate.org
>>>>>>> _______________________________________________
>>>>>>> hibernate-dev mailing list
>>>>>>> hibernate-dev at lists.jboss.org
>>>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>>>> 
>>>>> 
>>>>> --
>>>>> Steve Ebersole<steve at hibernate.org>
>>>>> http://hibernate.org
>>>>> _______________________________________________
>>>>> hibernate-dev mailing list
>>>>> hibernate-dev at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>>> 
>>> 
>>> --
>>> Steve Ebersole <steve at hibernate.org>
>>> http://hibernate.org
>>> 
> 
> 
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

-- 
Adam Warski
http://www.warski.org
http://www.softwaremill.eu

More information about the hibernate-dev mailing list