sebersole tbh, not sure which is the best option for ultimately handing this 19:54
sebersole seems like an exception should be thrown somewhere 19:54
sebersole as opposed to all of a sudden the call returning, but the session just being cleared 19:55
sebersole in which case, the method in my email response is even simplier... 19:55
smarlow basically, I'm saying to continue clearing the session from the afterCompletion sync but also set the flag, in case we are in the middle of a entitymanager call. in which case we detect that we mutated the session 19:56
sebersole in the "out of thread" case, we just immediately throw the exception 19:56
sebersole well but think about the user case 19:56
sebersole em.find(...) for example, from the user 19:56
sebersole all of a sudden em.find(..) returns 19:56
sebersole but 19:56
sebersole the em is cleared 19:57
sebersole no exception as to the rollback 19:57
sebersole maybe we need to do both 19:58
sebersole clear session/em and throw TransactionTimedOutException 19:59
sebersole although, we are simply guessing that the transaction timed out 19:59
smarlow we could build in a way to tell if the tx timedout 20:00
sebersole how? 20:00
sebersole you mean a jboss-specific way? 20:00
smarlow get jbossts/tm to give JBoss AS an extension way 20:00
smarlow like you were saying before I think, that we could use in jtaplatform 20:01
sebersole well the problem is as they said even success can come on a different thread 20:03
smarlow we should talk to tom again, because I wasn't clear on the success case. 20:03
smarlow I thought the success case wasn't one we wanted to detect 20:03
smarlow I think the success case explanation was more so that we understand why they can't always invoked afterCompletion in the application thread 20:04
sebersole first i'd like to understand our case, our desired outcome 20:05
sebersole we dont generally generate "extra" exceptions when a rollback comes through via the sync 20:06
sebersole why are we doing that here? 20:06
smarlow I think that someSessionMethod should throw an exception if we cleared the session from another thread, while someSessionMethod() was doing something 20:07
sebersole thats really the only reason that detecting between (a) afterCompletion from outside app thread and (b) afterCompletion from outside app thread that hapens to be a timeout is in any way relevant 20:07
sebersole we wont clear the session from another thread though 20:08
sebersole you see that right? 20:09
sebersole i mean the aftercompletion might come from that "other thread" 20:09
sebersole but the whole idea is that we delay the clear until we get "back inside" someSessionMethod back on the app thread 20:09
sebersole thats how you avoid the concurrent modification errors on the PC maps 20:10
smarlow I wanted to clear the session from that "other thread" in case we aren't in someSessionMethod already 20:10
sebersole i have yet to see that use case 20:10
smarlow so, we let the concurrent mod happen (which I don't like but looking for the lesser evil) 20:10
sebersole thats not the reported use case 20:10
sebersole the reported use case was that the concurrent call to afterCompletion happens during call to em.find 20:11
smarlow I agree that we can protect against the reported use case, your way 20:11
sebersole find is someSessionMethod 20:11
smarlow but I think my other (not reported) case, is also valid 20:12
smarlow where the app already called someSessionMethod is doing something else for a longer time than tx timeout 20:13
sebersole so the transaction times out after we return 20:13
smarlow yep and the app doesn't call entitymanager.anyOthermethods 20:13
sebersole i need to think about that one 20:13
sebersole like i said, i dont feel overly comfortable "making up" jta exceptions 20:14
smarlow I don't like that either 20:14
sebersole which, yes, is exactly what TransactionTimedOutException would be 20:14
smarlow the other path that I was thinking about, is push this case up the ee stack 20:15
smarlow and get some better way of dealing with this 20:15
smarlow where some other entitymanager callback is invoked from the app thread always for this case 20:15
smarlow with coordination from jta + ee containers 20:16
sebersole well thats possible for hibernate and jboss 20:16
sebersole but i dont think thats going to be standard thing, certainly not for > ee7 and i doubt for ee7 even 20:16
sebersole < ee7 i mean 20:17
smarlow I agree with you 20:17
smarlow it could be either an ee thing or a hibernate + jboss thing 20:17
sebersole i understand your desire to have this "work" in jboss 20:18
sebersole but you need to understand the need to have this "work" for Hibernate in all envs 20:18
smarlow if we could get it to work for jboss, the other envs could do something similar (possibly) 20:18
sebersole well the 'de facto' path is simply showing a "best alt" 20:19
sebersole so sure, they could 20:19
sebersole tbh, not sure i have the widest perspective though for choosing "best" here 20:20
sebersole we should discuss with jason 20:20
smarlow I think that we should come up with the best way without changing jboss as/jbosstm/ts but also keep in mind that if we completely hate all options, consider the jboss side path 20:20
sebersole well tbh i think the best option might be to recognize that the afterCompletion is coming from a diff thread and just throw an error 20:21
sebersole (and clear the session if enabled) 20:21
sebersole not so sure we have the best "context" to do any better than that 20:22
smarlow I suppose that the jtaplatform might be able to do better, if we could get some ee magic to help ensure the session clear does happen 20:25
sebersole i can already make sure the clear happens 20:25
sebersole i dont need "magic" for that 20:25
smarlow even when no other entitymanager.someMethods are invoked after the timeout occurs? 20:26
smarlow oh, I see, is that what you meant by "and clear the session if enabled"? 20:27
smarlow the afterCompletion sync would clear the session if enabled? 20:27
sebersole the afterCompletion synch would clear the session if enabled 20:27
sebersole the delay was simply an attempt to (a) not throw an exception and (b) have the session still be usable 20:28
sebersole not so sure thats the best outcome here 20:28