[hibernate-dev] Cassandra, ORM , Hibernate search, OGM
Hello, i was wondering is it OGM stable enough and will it support cassandra soon ? Saw on github that you are working on it.. thanks. ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] Cassandra, ORM , Hibernate search, OGM
Depends what you call soon and if you want to contribute :) But generally, I don't see it ready before a month or two at least. On 16 mars 2012, at 12:40, Теодор Димов wrote: > Hello, i was wondering is it OGM stable enough and will it support > cassandra soon ? Saw on github that you are working on it.. thanks. > ___ > hibernate-dev mailing list > hibernate-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
[hibernate-dev] [HV] Release plan for a version compatible with Bean Validation 1.1.0.Alpha1
Hi Hardy, Gunnar and all, I am thinking that we should get the ball rolling on an implementation of Hibernate Validator that supports Bean Validation 1.1.0.Alpha1 so that we can gather feedback. When do you think we can get an HV Alpha supporting the changes? What about a month? Emmanuel ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] JtaPlaform classes as internal?
In case anyone is interested: https://hibernate.onjira.com/browse/HHH-6823 https://hibernate.onjira.com/browse/HHH-5951 On Thu 15 Mar 2012 03:21:56 PM CDT, Steve Ebersole wrote: > I like #2 as well. There is already a JIRA for that. In addition there > is also a JIRA for adding some auto-detection in 5.0 > > On Thu 15 Mar 2012 11:40:07 AM CDT, Emmanuel Bernard wrote: >> Because you need to know the JtaPaltform class name to fill up >> hibernate.transaction.jta.platform, I find it curious that these >> classes are in internal. >> I might decide to delete one of them and not care as they are in >> internal but that will impact the user. >> >> I see two options: >> >> 1. create subclasses in a non internal package >> 2. create shortcuts for the built-in platforms (weblogic, >> websphere-5, websphere-6, etc) >> >> >> I like option 2 better as it makes configurations more readable. >> >> WDYT? >> ___ >> hibernate-dev mailing list >> hibernate-dev@lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev > -- st...@hibernate.org http://hibernate.org ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] JtaPlaform classes as internal?
Yes that covers it all. By the way these are perfect issues for somebody wanting to step up but not knowning the Hibernate code base. This is quite isolated. On 16 mars 2012, at 13:56, Steve Ebersole wrote: > In case anyone is interested: > > https://hibernate.onjira.com/browse/HHH-6823 > https://hibernate.onjira.com/browse/HHH-5951 > > > On Thu 15 Mar 2012 03:21:56 PM CDT, Steve Ebersole wrote: >> I like #2 as well. There is already a JIRA for that. In addition there is >> also a JIRA for adding some auto-detection in 5.0 >> >> On Thu 15 Mar 2012 11:40:07 AM CDT, Emmanuel Bernard wrote: >>> Because you need to know the JtaPaltform class name to fill up >>> hibernate.transaction.jta.platform, I find it curious that these classes >>> are in internal. >>> I might decide to delete one of them and not care as they are in internal >>> but that will impact the user. >>> >>> I see two options: >>> >>> 1. create subclasses in a non internal package >>> 2. create shortcuts for the built-in platforms (weblogic, websphere-5, >>> websphere-6, etc) >>> >>> >>> I like option 2 better as it makes configurations more readable. >>> >>> WDYT? >>> ___ >>> hibernate-dev mailing list >>> hibernate-dev@lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> > > -- > st...@hibernate.org > http://hibernate.org ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] [HV] Release plan for a version compatible with Bean Validation 1.1.0.Alpha1
Hi, On Mar 16, 2012, at 1:29 PM, Emmanuel Bernard wrote: > I am thinking that we should get the ball rolling on an implementation of > Hibernate Validator that supports Bean Validation 1.1.0.Alpha1 so that we can > gather feedback. the biggest problem is that we really want HV 4.3 being completely backward compatible. Implementing BV 1.1 would mean that we have to change some of the method level validation stuff. Really this would have to go into a HV 5 which in turn would mean we would need to create a branch and do parallel releases. Something I wanted to avoid. Really all the feature for method validation are already in place, just the API looks a little different. I could imagine that that we add things like ParameterNameProvider and implement the constructor validation methods. The methods would, however, still be hosted on org.hibernate.validator.method.MethodValidator. We can also try to get a HV 4.3 out asap just focusing on what's really required. Once it is out we start with HV 5 directly. Bottom line, HV 4.3 should work with BV 1.0 and any added features should be backwards compatible. Then w/ HV 5 we go BV 1.1. Personally I would like to avoid to work on two branches. Instead I would go for the second option where we maybe already add some things like ParameterNameProvider. --Hardy ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
[hibernate-dev] Sessions sharing Connections
Reference https://hibernate.onjira.com/browse/HHH-7020 and https://hibernate.onjira.com/browse/HHH-7090... Essentially, having 2 sessions share a JDBC connection is currently broken. Adam, Lukasz and I discussed this on the mailing list a few months ago and Shawn has been helping me investigating the last few days. The solution end solution is to have the 2 sessions share both the TransactionCoordinator and LogicalConnection, but use separate JdbcCoordinators. We could get away with them sharing a JdbcCoordinator as well, but that opens up (slight) potential concurrency issues if the 2 sessions are used concurrently. The concurrency issues here are not on the same level as those if using a session concurrently. Mainly JdbcCoordinator manages the "current JDBC batch" if the session is using JDBC statement batching. Concurrent access could mean batch circumvention (aka, 1 statement executed in the batch instead of the batch size) if both sessions are performing writes concurrently. All the above is a bit specific, but the ultimate question/decision here is that in order to not reuse JdbcCoordinators requires *major* SPI changes. Basically we need to invert the relationship between JdbcCoordinator and TransactionCoordinator. Currently Session holds a TransactionCoordinator and that TransactionCoordinator is responsible for managing the JdbcCoordinator. The "proper" change would require that instead Session hold a JdbcCoordinator which is responsible for managing a TransactionCoordinator. A consideration here is that these are SPIs and should not really be changing between point releases. But another thing to consider is that these particular SPIs were added in 4.0, so they are relatively new, and that, in this particular case at least, they are just plain wrong. What do y'all think between these 2 options? -- st...@hibernate.org http://hibernate.org ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] JtaPlaform classes as internal?
Good point. I added that flag to the JIRAs On Fri 16 Mar 2012 08:06:53 AM CDT, Emmanuel Bernard wrote: > Yes that covers it all. > By the way these are perfect issues for somebody wanting to step up but not > knowning the Hibernate code base. This is quite isolated. > > On 16 mars 2012, at 13:56, Steve Ebersole wrote: > >> In case anyone is interested: >> >> https://hibernate.onjira.com/browse/HHH-6823 >> https://hibernate.onjira.com/browse/HHH-5951 >> >> >> On Thu 15 Mar 2012 03:21:56 PM CDT, Steve Ebersole wrote: >>> I like #2 as well. There is already a JIRA for that. In addition there is >>> also a JIRA for adding some auto-detection in 5.0 >>> >>> On Thu 15 Mar 2012 11:40:07 AM CDT, Emmanuel Bernard wrote: Because you need to know the JtaPaltform class name to fill up hibernate.transaction.jta.platform, I find it curious that these classes are in internal. I might decide to delete one of them and not care as they are in internal but that will impact the user. I see two options: 1. create subclasses in a non internal package 2. create shortcuts for the built-in platforms (weblogic, websphere-5, websphere-6, etc) I like option 2 better as it makes configurations more readable. WDYT? ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev >>> >> >> -- >> st...@hibernate.org >> http://hibernate.org > -- st...@hibernate.org http://hibernate.org ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] [HV] Release plan for a version compatible with Bean Validation 1.1.0.Alpha1
On 16 mars 2012, at 14:17, Hardy Ferentschik wrote: > We can also try to get a HV 4.3 out asap just focusing on what's really > required. Once it is out we start with HV 5 directly. I'm for that option personally. ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] JtaPlaform classes as internal?
I was just thinking about this related eg discussion http://java.net/projects/jpa-spec/lists/jsr338-experts/archive/2011-10/message/3 from last fall and wonder if the default could be something like: if attempt to use jndi naming and lookup TransactionSynchronizationRegistry works, use the TSR. else, look for hints in the environment (standalone case since all EE implementations should be using TSR). This could also cover use on EE servers that are either non-compliant or for other reason cannot return the TSR. On 03/16/2012 09:28 AM, Steve Ebersole wrote: > Good point. I added that flag to the JIRAs > > On Fri 16 Mar 2012 08:06:53 AM CDT, Emmanuel Bernard wrote: >> Yes that covers it all. >> By the way these are perfect issues for somebody wanting to step up but not >> knowning the Hibernate code base. This is quite isolated. >> >> On 16 mars 2012, at 13:56, Steve Ebersole wrote: >> >>> In case anyone is interested: >>> >>> https://hibernate.onjira.com/browse/HHH-6823 >>> https://hibernate.onjira.com/browse/HHH-5951 >>> >>> >>> On Thu 15 Mar 2012 03:21:56 PM CDT, Steve Ebersole wrote: I like #2 as well. There is already a JIRA for that. In addition there is also a JIRA for adding some auto-detection in 5.0 On Thu 15 Mar 2012 11:40:07 AM CDT, Emmanuel Bernard wrote: > Because you need to know the JtaPaltform class name to fill up > hibernate.transaction.jta.platform, I find it curious that these classes > are in internal. > I might decide to delete one of them and not care as they are in internal > but that will impact the user. > > I see two options: > > 1. create subclasses in a non internal package > 2. create shortcuts for the built-in platforms (weblogic, websphere-5, > websphere-6, etc) > > > I like option 2 better as it makes configurations more readable. > > WDYT? > ___ > hibernate-dev mailing list > hibernate-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev >>> >>> -- >>> st...@hibernate.org >>> http://hibernate.org >> > ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] JtaPlaform classes as internal?
Unfortunately JtaPlatform covers more than just sync registration... On Fri 16 Mar 2012 09:43:45 AM CDT, Scott Marlow wrote: > I was just thinking about this related eg discussion > http://java.net/projects/jpa-spec/lists/jsr338-experts/archive/2011-10/message/3 > > from last fall and wonder if the default could be something like: > > if attempt to use jndi naming and lookup > TransactionSynchronizationRegistry works, use the TSR. > > else, look for hints in the environment (standalone case since all EE > implementations should be using TSR). This could also cover use on EE > servers that are either non-compliant or for other reason cannot > return the TSR. > > > On 03/16/2012 09:28 AM, Steve Ebersole wrote: >> Good point. I added that flag to the JIRAs >> >> On Fri 16 Mar 2012 08:06:53 AM CDT, Emmanuel Bernard wrote: >>> Yes that covers it all. >>> By the way these are perfect issues for somebody wanting to step up >>> but not knowning the Hibernate code base. This is quite isolated. >>> >>> On 16 mars 2012, at 13:56, Steve Ebersole wrote: >>> In case anyone is interested: https://hibernate.onjira.com/browse/HHH-6823 https://hibernate.onjira.com/browse/HHH-5951 On Thu 15 Mar 2012 03:21:56 PM CDT, Steve Ebersole wrote: > I like #2 as well. There is already a JIRA for that. In addition > there is also a JIRA for adding some auto-detection in 5.0 > > On Thu 15 Mar 2012 11:40:07 AM CDT, Emmanuel Bernard wrote: >> Because you need to know the JtaPaltform class name to fill up >> hibernate.transaction.jta.platform, I find it curious that these >> classes are in internal. >> I might decide to delete one of them and not care as they are in >> internal but that will impact the user. >> >> I see two options: >> >> 1. create subclasses in a non internal package >> 2. create shortcuts for the built-in platforms (weblogic, >> websphere-5, websphere-6, etc) >> >> >> I like option 2 better as it makes configurations more readable. >> >> WDYT? >> ___ >> hibernate-dev mailing list >> hibernate-dev@lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev > -- st...@hibernate.org http://hibernate.org >>> >> > -- st...@hibernate.org http://hibernate.org ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] JtaPlaform classes as internal?
Yes, but I wonder if we could squash down what we require to what http://docs.oracle.com/javaee/5/api/javax/transaction/TransactionSynchronizationRegistry.html offers. We aren't the only persistence provider still using the Transaction Manager directly either. I still like my original proposal to introduce a standard way of accessing the TM but if we truly could avoid using the TM (when running with a EE server), that might be worth attempting. On 03/16/2012 10:45 AM, Steve Ebersole wrote: > Unfortunately JtaPlatform covers more than just sync registration... > > > On Fri 16 Mar 2012 09:43:45 AM CDT, Scott Marlow wrote: >> I was just thinking about this related eg discussion >> http://java.net/projects/jpa-spec/lists/jsr338-experts/archive/2011-10/message/3 >> from last fall and wonder if the default could be something like: >> >> if attempt to use jndi naming and lookup >> TransactionSynchronizationRegistry works, use the TSR. >> >> else, look for hints in the environment (standalone case since all EE >> implementations should be using TSR). This could also cover use on EE >> servers that are either non-compliant or for other reason cannot >> return the TSR. >> >> >> On 03/16/2012 09:28 AM, Steve Ebersole wrote: >>> Good point. I added that flag to the JIRAs >>> >>> On Fri 16 Mar 2012 08:06:53 AM CDT, Emmanuel Bernard wrote: Yes that covers it all. By the way these are perfect issues for somebody wanting to step up but not knowning the Hibernate code base. This is quite isolated. On 16 mars 2012, at 13:56, Steve Ebersole wrote: > In case anyone is interested: > > https://hibernate.onjira.com/browse/HHH-6823 > https://hibernate.onjira.com/browse/HHH-5951 > > > On Thu 15 Mar 2012 03:21:56 PM CDT, Steve Ebersole wrote: >> I like #2 as well. There is already a JIRA for that. In addition >> there is also a JIRA for adding some auto-detection in 5.0 >> >> On Thu 15 Mar 2012 11:40:07 AM CDT, Emmanuel Bernard wrote: >>> Because you need to know the JtaPaltform class name to fill up >>> hibernate.transaction.jta.platform, I find it curious that these >>> classes are in internal. >>> I might decide to delete one of them and not care as they are in >>> internal but that will impact the user. >>> >>> I see two options: >>> >>> 1. create subclasses in a non internal package >>> 2. create shortcuts for the built-in platforms (weblogic, >>> websphere-5, websphere-6, etc) >>> >>> >>> I like option 2 better as it makes configurations more readable. >>> >>> WDYT? >>> ___ >>> hibernate-dev mailing list >>> hibernate-dev@lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> > > -- > st...@hibernate.org > http://hibernate.org >>> >> > ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] [infinispan-dev] [jboss-as7-dev] AS7-4007 missing Infinispan dependency for clustered JPA second level cache
On Mar 14, 2012, at 7:52 PM, Scott Marlow wrote: > On 03/14/2012 02:13 PM, Manik Surtani wrote: >> >> On 6 Mar 2012, at 14:45, Scott Marlow wrote: >> - Medium term: Have a way to pass in marshalling configurations per cache manager and per-cache (or an abstraction of it), which allows the right class resolver to be passed in. (***) https://issues.jboss.org/browse/ISPN-1367 >>> >>> ISPN-1367 is targeted to Infinispan 5.2, any idea of the target release >>> date for that? I'm curious as to which AS release it might align with. >> >> Definitely post EAP 6. > > The ISPN-1367 jira changed a bit since I asked this question. A few > days ago, Galder said that he was working on addressing ISPN-1367 for AS > 7.1.2 (so we can specify the AS7 ModularClassResolver as a global > configuration setting passed into Infinispan). > > I probably asked the wrong question above (I don't really want to bring > 5.2 into As 7.1.2). Can we fix ISPN-1367 in a 5.1.x.FINAL build, that > could be brought into AS 7.1.2? yes > >> >> -- >> Manik Surtani >> ma...@jboss.org >> twitter.com/maniksurtani >> >> Lead, Infinispan >> http://www.infinispan.org >> >> >> >> ___ >> hibernate-dev mailing list >> hibernate-dev@lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev > > ___ > infinispan-dev mailing list > infinispan-...@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev -- Galder Zamarreño Sr. Software Engineer Infinispan, JBoss Cache ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] [HV] Release plan for a version compatible with Bean Validation 1.1.0.Alpha1
Am 16.03.2012 15:08 schrieb "Emmanuel Bernard" : > > > On 16 mars 2012, at 14:17, Hardy Ferentschik wrote: > > > We can also try to get a HV 4.3 out asap just focusing on what's really required. Once it is out we start with HV 5 directly. > > I'm for that option personally. > +1 That's also my preference. Let's get out a strictly backwards-compatible HV 4.3 asap, and then proceed with HV 5 as first release based on BV 1.1. I'm not sure though, whether we'll have a first Alpha ready within one month, given that we have to finalize 4.3 before. --Gunnar ___ > hibernate-dev mailing list > hibernate-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] JtaPlaform classes as internal?
Well we could with some caveats. 1) If using a TSR-backed JtaPlatform no features leveraging suspend/resume would be available; this includes (limited to?) org.hibernate.engine.transaction.internal.jta.JtaIsolationDelegate 2) Infinispan has its notion of a "TransactionManagerLookup", and hibernate-infinispan has an impl that bridges through to our JtaPlatform to retrieve the TM. No clue the ramification here. Though I can't imagine that Infinispan needs suspend/resume. On Fri 16 Mar 2012 09:54:23 AM CDT, Scott Marlow wrote: > Yes, but I wonder if we could squash down what we require to what > http://docs.oracle.com/javaee/5/api/javax/transaction/TransactionSynchronizationRegistry.html > > offers. > > We aren't the only persistence provider still using the Transaction > Manager directly either. I still like my original proposal to > introduce a standard way of accessing the TM but if we truly could > avoid using the TM (when running with a EE server), that might be > worth attempting. > > On 03/16/2012 10:45 AM, Steve Ebersole wrote: >> Unfortunately JtaPlatform covers more than just sync registration... >> >> >> On Fri 16 Mar 2012 09:43:45 AM CDT, Scott Marlow wrote: >>> I was just thinking about this related eg discussion >>> http://java.net/projects/jpa-spec/lists/jsr338-experts/archive/2011-10/message/3 >>> >>> >>> from last fall and wonder if the default could be something like: >>> >>> if attempt to use jndi naming and lookup >>> TransactionSynchronizationRegistry works, use the TSR. >>> >>> else, look for hints in the environment (standalone case since all EE >>> implementations should be using TSR). This could also cover use on EE >>> servers that are either non-compliant or for other reason cannot >>> return the TSR. >>> >>> >>> On 03/16/2012 09:28 AM, Steve Ebersole wrote: Good point. I added that flag to the JIRAs On Fri 16 Mar 2012 08:06:53 AM CDT, Emmanuel Bernard wrote: > Yes that covers it all. > By the way these are perfect issues for somebody wanting to step up > but not knowning the Hibernate code base. This is quite isolated. > > On 16 mars 2012, at 13:56, Steve Ebersole wrote: > >> In case anyone is interested: >> >> https://hibernate.onjira.com/browse/HHH-6823 >> https://hibernate.onjira.com/browse/HHH-5951 >> >> >> On Thu 15 Mar 2012 03:21:56 PM CDT, Steve Ebersole wrote: >>> I like #2 as well. There is already a JIRA for that. In addition >>> there is also a JIRA for adding some auto-detection in 5.0 >>> >>> On Thu 15 Mar 2012 11:40:07 AM CDT, Emmanuel Bernard wrote: Because you need to know the JtaPaltform class name to fill up hibernate.transaction.jta.platform, I find it curious that these classes are in internal. I might decide to delete one of them and not care as they are in internal but that will impact the user. I see two options: 1. create subclasses in a non internal package 2. create shortcuts for the built-in platforms (weblogic, websphere-5, websphere-6, etc) I like option 2 better as it makes configurations more readable. WDYT? ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev >>> >> >> -- >> st...@hibernate.org >> http://hibernate.org > >>> >> > -- st...@hibernate.org http://hibernate.org ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] Sessions sharing Connections
I lean towards the proper fix as I think in its current state the connection() and transactionContext() are not usable at all (especially with the connection leaks). In a perfect world it would have been caught prior to 4 release but that horse has left the barn. The SPIs like you said are new to 4 so there might not be a whole lot of people leveraging them, and if they are, they're probably running into the same types of issues we've been discussing. (and even worse, might be hitting them and not noticing) In the end though, if the concurrency issues are indeed as slight as you think and the SPI changes aren't acceptable, then it might be worthwhile to live with that (and document it explicitly) and then fix it properly when you rev to 5. -Original Message- From: hibernate-dev-boun...@lists.jboss.org [mailto:hibernate-dev-boun...@lists.jboss.org] On Behalf Of Steve Ebersole Sent: Friday, March 16, 2012 7:28 AM To: hibernate-dev@lists.jboss.org Subject: [hibernate-dev] Sessions sharing Connections Reference https://hibernate.onjira.com/browse/HHH-7020 and https://hibernate.onjira.com/browse/HHH-7090... Essentially, having 2 sessions share a JDBC connection is currently broken. Adam, Lukasz and I discussed this on the mailing list a few months ago and Shawn has been helping me investigating the last few days. The solution end solution is to have the 2 sessions share both the TransactionCoordinator and LogicalConnection, but use separate JdbcCoordinators. We could get away with them sharing a JdbcCoordinator as well, but that opens up (slight) potential concurrency issues if the 2 sessions are used concurrently. The concurrency issues here are not on the same level as those if using a session concurrently. Mainly JdbcCoordinator manages the "current JDBC batch" if the session is using JDBC statement batching. Concurrent access could mean batch circumvention (aka, 1 statement executed in the batch instead of the batch size) if both sessions are performing writes concurrently. All the above is a bit specific, but the ultimate question/decision here is that in order to not reuse JdbcCoordinators requires *major* SPI changes. Basically we need to invert the relationship between JdbcCoordinator and TransactionCoordinator. Currently Session holds a TransactionCoordinator and that TransactionCoordinator is responsible for managing the JdbcCoordinator. The "proper" change would require that instead Session hold a JdbcCoordinator which is responsible for managing a TransactionCoordinator. A consideration here is that these are SPIs and should not really be changing between point releases. But another thing to consider is that these particular SPIs were added in 4.0, so they are relatively new, and that, in this particular case at least, they are just plain wrong. What do y'all think between these 2 options? -- st...@hibernate.org http://hibernate.org ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] Sessions sharing Connections
> We could get away with them sharing a JdbcCoordinator as well, but that > opens up (slight) potential concurrency issues if the 2 sessions are > used concurrently. The question really is about the use cases. Are connections supposed to be used concurrently anyway? I think they are usually used by a single thread at a time. The Envers's use case is to create another session where some data can be read, not influencing what the original session held. > A consideration here is that these are SPIs and should not really be > changing between point releases. But another thing to consider is that > these particular SPIs were added in 4.0, so they are relatively new, and > that, in this particular case at least, they are just plain wrong. Although, if something is plain wrong, I would fix it as fast as possible :). Treat it as a bug, I suppose SPIs can have bugs as well ;) Adam -- Adam Warski http://twitter.com/#!/adamwarski http://www.softwaremill.com http://www.warski.org ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
