[hibernate-dev] Integrator and retrieving objects

Emmanuel Bernard emmanuel at hibernate.org
Tue Apr 26 14:04:52 EDT 2011


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
>> 





More information about the hibernate-dev mailing list