[hibernate-dev] Integrator and retrieving objects

Wed Apr 27 10:00:31 EDT 2011

Right, I don't think the "its stateless" approach will work as the 
general rule.

On 04/27/2011 03:48 AM, Adam Warski wrote:
> 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
>

-- 
Steve Ebersole <steve at hibernate.org>
http://hibernate.org