[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-2860?page=c... ] Steve Ebersole updated HHH-2860: -------------------------------- Fix Version/s: (was: 3.3.0.CR1) 3.3.0 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators.... - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-2860?page=c... ] Shawn Clowater commented on HHH-2860: ------------------------------------- Steve, out of curiosity what type of work is going to fall under this umbrella? I'm really liking the Work API to perform low level operations on the JDBC connection and also love the fact that it ties in with the connection running in the session as we have cases were we do some updating of the client info, enabling/disabling Oracle tracing as a config option, etc so that all fits very nicely. There is concept we're using the .connection() for and I'm not sure if there's a better of even a way to do it but we have some cases where we're running in a session and have configured a set of filters on it but want to look up a piece of data using another set of filters, no filters, whatever and don't want to restricted to the already filtered data. In addition we are sometimes looking up this data to perform some sort of validation check as data is being saved and don't want to trigger an infinite loop of flushes. (although I suppose we could tweak the flushmode at that point). The goal is to have access to anything that might have been sent to the db w/o an explicit commit and/or write some audit logging data without having it fill up in the main session. So we're doing something like this... return HibernateConfigurationHelper.getSessionFactory().openSession(currentSession().connection(), new HibernateInterceptor()); So in essence we are just wanting to piggyback off the existing connection/transaction and then have the controlling session handle the transaction commit/rollback. It does have the side effect of spewing ON_CLOSE warnings since the connection was provided to the Session. After I updated to 3.3 SP1 the other day I started looking for alternate ways to do this and stumbled across the the public Session getSession(EntityMode entityMode) from SessionImplementor that states /** * Starts a new Session with the given entity mode in effect. This secondary * Session inherits the connection, transaction, and other context * information from the primary Session. It doesn't need to be flushed * or closed by the developer. * * @param entityMode The entity mode to use for the new session. * @return The new session */ This sounded exactly what I wanted to do and started retooling some code and testing only to come and find out that if you specify the same EntityMode then it just returns the instance of that you make the call on. from SessionImpl if ( this.entityMode == entityMode ) { return this; } So in the end this doesn't really give me the feature I want and it is so close yet so far. I guess since .connection() is going to go way and the jdbc context isn't exposed in the Session interface to get at the connection that way (which really doesn't feel right) I was wondering if there would be a way to get this piggy back behavior for the sessions. I don't know if it would fit in the getSession(EntityMode) concept but it would be nice to be able to get a new session out of that. It would be added to the child sessions map for transparent flushing, etc as it is now but it would also be a nice feature if the child session could be flushed/closed independently and that closing it would remove it from the child map. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators.... - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-2860?page=c... ] Steve Ebersole commented on HHH-2860: ------------------------------------- Hmmm, seems these code tags are not working the way Atlassian thinks they are supposed to :) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators.... - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-2860?page=c... ] Steve Ebersole updated HHH-2860: -------------------------------- Fix Version/s: (was: 3.5.0.Beta-1) 3.5-tmp -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators.... - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-2860?page=c... ] Steve Ebersole updated HHH-2860: -------------------------------- Fix Version/s: 4.0.0.Alpha2 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators.... - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-2860?page=c... ] Steve Ebersole closed HHH-2860. ------------------------------- Resolution: Fixed -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators.... - For more information on JIRA, see: http://www.atlassian.com/software/jira