[hibernate-issues] [Hibernate-JIRA] Issue Comment Edited: (HHH-5490) dirty data be inserted into 2L cache

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-5490?page=c... ] Steve Ebersole edited comment on HHH-5490 at 9/15/10 12:22 PM: --------------------------------------------------------------- Aug 31 00:11:55 <stliu_> sebersole, sorry, network dropped Aug 31 00:12:12 <stliu_> last msg [23:53] <stliu> yes, that's true, but can't we delay the cache happens after tx complete? Aug 31 00:13:36 <sebersole> stliu_: you missed alot\ Aug 31 00:14:00 <sebersole> [10:55] <sebersole> take the second case... how would that work? Aug 31 00:14:11 <sebersole> [11:07] <sebersole> to answer your question specifically, i dont know that we dont wait already Aug 31 00:14:15 <sebersole> [11:08] <sebersole> the problem is that we see "authoritative reads" come "over top of it" Aug 31 00:14:20 <sebersole> [11:08] <sebersole> like i said, putFromRead makes certain assumptions Aug 31 00:14:25 <sebersole> [11:09] <sebersole> in the first case (refresh) there is a way to circumvent that, because we know the entity's EntityEntry Aug 31 00:14:29 <sebersole> [11:10] <sebersole> we can check it for the entry's current status and act accordingly Aug 31 00:14:33 <sebersole> [11:11] <sebersole> (essentially route the cache data refresh logic through the same process that occurs for generated property values, whcih is what those people should be doing anyway) Aug 31 00:14:38 <sebersole> [11:11] <sebersole> as i said, though, i am not sure what you base that decision on in this second case Aug 31 00:15:17 <sebersole> (and jira is back) Aug 31 00:18:15 <stliu_> looking Aug 31 00:40:51 <sebersole> stliu_: out of curiosity, the entity is not "served" from the L2 cache right (in the second case)? Aug 31 00:41:29 <stliu_> the second get? Aug 31 00:41:34 <sebersole> right Aug 31 00:41:54 <sebersole> no Aug 31 00:41:58 <sebersole> sorry, the first Aug 31 00:42:04 <stliu_> yes Aug 31 00:42:42 <stliu_> it haven't been putted into 2l cache by the insert Aug 31 00:44:53 <sebersole> what cache? Aug 31 00:45:15 <sebersole> for a non-transactional cache it should have Aug 31 00:45:31 <sebersole> but it should have just been a "holder" + lock Aug 31 00:45:42 <sebersole> just trying to make sure that part is all working Aug 31 00:46:32 <sebersole> pretty sure the first case is not overly difficult to account for, ust trying to fathom this second case.. Aug 31 00:48:32 <stliu_> readwritecache Aug 31 00:48:42 <stliu_> sebersole, ^^ Aug 31 00:48:50 <sebersole> stliu_: yep, ^^ Aug 31 11:13:44 <sebersole> stliu_: you need any guidance on that case? Aug 31 11:13:55 <sebersole> about to drop off Aug 31 11:14:03 <stliu_> sebersole, yeah, please Aug 31 11:15:23 <stliu_> sebersole, i mean the guidance :D Aug 31 11:17:20 <sebersole> you have specific questions? Aug 31 11:18:18 <stliu_> i dont sure where to apply the entityentry's state you mentioned Aug 31 11:19:52 <sebersole> in the refresh event listener Aug 31 11:20:40 <sebersole> it sort of depends on its status Aug 31 11:20:48 <sebersole> what is the status on the refresh? Aug 31 11:21:05 <sebersole> it was flushed, so MANAGED? Aug 31 11:21:08 <stliu_> loading Aug 31 11:21:39 <sebersole> before the refresh listener sets it to that i mean Aug 31 11:21:55 <sebersole> it'll either be SAVING or MANAGED Aug 31 11:22:13 <stliu_> yeah Aug 31 11:22:22 <sebersole> well which? ;) Aug 31 11:22:30 <sebersole> its a very important distinction Aug 31 11:24:02 <stliu_> it is managed Aug 31 11:25:14 <sebersole> ugh Aug 31 11:28:17 <sebersole> essentially we need a way to identify entities which were created in this current transaction, and we dont have that in either case here Aug 31 11:29:33 <sebersole> i quick hack would be to keep a journal of the EntityKeys created on the PC and clear it on transaction completion Aug 31 11:30:31 <stliu_> sebersole, i also looked org.hibernate.engine.TwoPhaseLoad.initializeEntity(Object, boolean, SessionImplementor, PreLoadEvent, PostLoadEvent) Aug 31 11:31:03 <sebersole> tbh, i wonder if we have the same issue with generated properties Aug 31 11:31:11 <stliu_> i'm wondering is it possible to use a AfterTransactionCompletionProcess instead of put to cache after load immediately Aug 31 11:31:42 <sebersole> god lor no Aug 31 11:32:09 <sebersole> what does that buy you anyway? Aug 31 11:32:17 <sebersole> you'd still do the put Aug 31 11:33:33 <stliu_> but we can check if the tx success Aug 31 11:34:16 <sebersole> then how do you propse to stop other sessions from writing that data to cache? Aug 31 11:35:37 <sebersole> i think you are trying to "fix it up on the back end" Aug 31 11:35:56 <sebersole> the problem is not the put into the cache on refresh Aug 31 11:36:22 <sebersole> the problem is that we lose sight of the fact that this entity was just inserted and is not permenant yet Aug 31 11:37:48 <stliu_> is it only just inserted? what about updated Aug 31 11:38:39 <sebersole> in 99% of cases when we read data from a result set it is safe to assume it is persistent data (as in released from dbs transaction log) Aug 31 11:39:13 <sebersole> well in your first use case thats simply not a concern Aug 31 11:41:34 <sebersole> stliu_: did you try this first case with generated properties? Aug 31 11:41:48 <stliu_> yes, i did Aug 31 11:41:53 <sebersole> and? Aug 31 11:42:13 <stliu_> the current test case i'm using is with a generated property Aug 31 11:42:14 <stliu_> @Generated(GenerationTime.ALWAYS) Aug 31 11:42:14 <stliu_> @Column(columnDefinition="bigint default '1'") Aug 31 11:42:14 <stliu_> private Long price; Aug 31 11:42:33 <stliu_> same behavior Aug 31 11:47:37 <sebersole> so probably these 2 cases (refresh and generation) need to be handled specially in terms of putting into the cache Aug 31 11:48:24 <sebersole> though, tbh, i dont see how property-generation does the same incorrect thing Aug 31 11:49:19 <sebersole> it simply reads the generated state and rebuilds the "state to cache" prior to ever calling the cache Aug 31 11:54:43 <stliu_> yes, but when do it with refresh, internally it uses twophaseload to load the entity, and with in this class, it performs the cacheing Aug 31 11:55:38 <sebersole> [22:42] <stliu_> same behavior Aug 31 11:55:52 <sebersole> i asked if property generation worked or failed Aug 31 11:55:59 <sebersole> you said it had the same behavior Aug 31 11:56:25 <stliu_> the property generation worked but the test case fails Aug 31 11:56:39 <sebersole> um, huh Aug 31 11:57:20 <sebersole> does property generation suffer from this same thing? Aug 31 11:58:00 <stliu_> no, actually not much relates to property generation Aug 31 11:58:39 <sebersole> i have no idea what that means Aug 31 11:59:44 <stliu_> i know the refresh is for property generation Aug 31 12:01:06 <stliu_> this bug does not releates to the property generation code probably Aug 31 12:01:34 <stliu_> like you said, the data is not permenant yet, see case 2 Aug 31 12:01:43 <sebersole> stliu_: look at it like this... Aug 31 12:02:06 <sebersole> your first use case is really a property generation use case Aug 31 12:02:27 <sebersole> and propertu generation works as designed and as it is supposed to Aug 31 12:02:31 <sebersole> so... Aug 31 12:02:52 <sebersole> doesnt it make sense to have this use case operate more like that> Aug 31 12:03:14 <sebersole> i mean thats just a high level swag Aug 31 12:03:28 <sebersole> but that seems pretty logical/reasonable right? Aug 31 12:03:33 <stliu_> yes Aug 31 12:04:34 <sebersole> the problem there is that we lose the "context" there on the entity entry Aug 31 12:05:05 <sebersole> such that when we come back into it for the refresh we have no idea that we just inserted or updated it in this txn Aug 31 12:05:36 <sebersole> to me, thats the issue Aug 31 12:05:43 <stliu_> yes, agree Aug 31 12:06:10 <sebersole> delaying putting reads from the database into the cache until commit it not a resolution Aug 31 12:06:32 <sebersole> anyway, all that is for the refresh case Aug 31 12:06:42 <sebersole> the clear case is different Aug 31 12:07:12 <sebersole> tbh, not sure what we would do there Aug 31 12:07:19 <stliu_> yes, i think you're right :) Aug 31 12:07:37 <stliu_> that will make lots of changes, right Aug 31 12:07:51 <sebersole> stliu_: depends on how it is done Aug 31 12:09:43 <sebersole> even if we fixed it, property generation is far more efficient Aug 31 12:10:01 <sebersole> i mean sounds like bitching just for the sake of bitching Aug 31 12:10:54 <sebersole> i can get to it late wed or into thursday Aug 31 12:11:16 <sebersole> but really see above Aug 31 12:11:25 <stliu_> okay， thanks Aug 31 12:12:47 <sebersole> stliu_: i mean as of now, perhaps the only *real* solution s to invalidate the corresponding second level cache entries on clear Aug 31 12:17:16 <sebersole> if you clear the session of entities that were inserted or updated during this transaction we for the cache entires to invalidate after trasaction Aug 31 12:17:41 <sebersole> on fail, that is Aug 31 12:17:50 <sebersole> since we simply do not know Aug 31 12:18:50 <sebersole> eventually i can see a "gatekeeper" for the second level cache Aug 31 12:19:17 <sebersole> one per session i mean Aug 31 12:20:16 <sebersole> it could keep track of keys added for various operations Aug 31 12:20:27 <sebersole> and on rollback do some clean up Aug 31 12:20:46 <stliu_> will it cause other concurrent sessions see the dirty data before the *insert* session's tx complete/rollback? Aug 31 12:21:08 <sebersole> it wont do anything different than what it does right now Aug 31 12:21:19 <sebersole> in terms of putting stuff into the cache Aug 31 12:21:52 <sebersole> but for example, when we ask the gatekeeper to do delegate an insert... Aug 31 12:22:07 <sebersole> org.hibernate.cache.access.EntityRegionAccessStrategy#insert Aug 31 12:22:19 <sebersole> it'll keep track of that key Aug 31 12:22:33 <sebersole> and the fact that it was inserted during the current transaction Aug 31 12:23:54 <sebersole> when it sees the "put from read" it can see that the same key was also added via insert previously Aug 31 12:24:07 <sebersole> really its just doing some journaling Aug 31 12:24:11 <sebersole> so that... Aug 31 12:24:32 <sebersole> if/when the txn rollbacks back we know that we need to invalidate said key Aug 31 12:25:27 <sebersole> another option is to make it smart in terms of how and when it releases the cache puts Aug 31 12:25:55 <sebersole> aka in the above case, we already have the cache entry in place from the insert Aug 31 12:26:16 <sebersole> we could delay the put from read until successful transaction completion Aug 31 12:26:35 <sebersole> stliu_: make sense? Aug 31 12:26:40 <stliu_> this is what i was looking for? Aug 31 12:26:47 * ?// :Unknown command Aug 31 12:26:55 <stliu_> s/?// Aug 31 12:26:55 <sebersole> no you wanted to delay all puts Aug 31 12:27:04 <sebersole> oh ok Aug 31 12:27:25 <sebersole> but yes, that is a lot of work Aug 31 12:27:32 <sebersole> either way Aug 31 12:28:47 <sebersole> anyway, off to bed Aug 31 12:28:51 <sebersole> night all was (Author: stliu): Aug 31 00:11:55 <stliu_> sebersole, sorry, network dropped Aug 31 00:12:04 <sebersole> hardy_: i talked to christian Aug 31 00:12:12 <stliu_> last msg [23:53] <stliu> yes, that's true, but can't we delay the cache happens after tx complete? Aug 31 00:12:30 <sebersole> he has not done any of the docbook integration work Aug 31 00:12:44 <hardy_> i see Aug 31 00:13:08 <sebersole> and would rather just sit there and tell me how i really ought to just switch to xhtml+lemma and write translation tools myself Aug 31 00:13:22 <sebersole> (if you know christian, you know what i mean) ;) Aug 31 00:13:32 <hardy_> i know exactly what you mean Aug 31 00:13:36 <sebersole> stliu_: you missed alot\ Aug 31 00:14:00 <sebersole> [10:55] <sebersole> take the second case... how would that work? Aug 31 00:14:11 <sebersole> [11:07] <sebersole> to answer your question specifically, i dont know that we dont wait already Aug 31 00:14:15 <sebersole> [11:08] <sebersole> the problem is that we see "authoritative reads" come "over top of it" Aug 31 00:14:20 <sebersole> [11:08] <sebersole> like i said, putFromRead makes certain assumptions Aug 31 00:14:25 <sebersole> [11:09] <sebersole> in the first case (refresh) there is a way to circumvent that, because we know the entity's EntityEntry Aug 31 00:14:29 <sebersole> [11:10] <sebersole> we can check it for the entry's current status and act accordingly Aug 31 00:14:33 <sebersole> [11:11] <sebersole> (essentially route the cache data refresh logic through the same process that occurs for generated property values, whcih is what those people should be doing anyway) Aug 31 00:14:38 <sebersole> [11:11] <sebersole> as i said, though, i am not sure what you base that decision on in this second case Aug 31 00:15:17 <sebersole> (and jira is back) Aug 31 00:18:15 <stliu_> looking Aug 31 00:19:37 <sebersole> anyone have thoughts on HHH-2224 Aug 31 00:19:38 <jbossbot> jira [HHH-2224] executeUpdate causes coarse cache invalidation [Open, Major, Unassigned] http://opensource.atlassian.com/projects/hibernate/browse/HHH-2224 Aug 31 00:19:50 <sebersole> i find that i am sometimes too strict Aug 31 00:20:22 <sebersole> basically they are asking for a way to not have bulk hql operations invalidate the query cache Aug 31 00:20:47 <sebersole> grr, sorry Aug 31 00:20:52 <sebersole> not the query cache Aug 31 00:20:58 <sebersole> the second level cache Aug 31 00:40:51 <sebersole> stliu_: out of curiosity, the entity is not "served" from the L2 cache right (in the second case)? Aug 31 00:41:29 <stliu_> the second get? Aug 31 00:41:34 <sebersole> right Aug 31 00:41:54 <sebersole> no Aug 31 00:41:58 <sebersole> sorry, the first Aug 31 00:42:04 <stliu_> yes Aug 31 00:42:42 <stliu_> it haven't been putted into 2l cache by the insert Aug 31 00:44:53 <sebersole> what cache? Aug 31 00:45:15 <sebersole> for a non-transactional cache it should have Aug 31 00:45:31 <sebersole> but it should have just been a "holder" + lock Aug 31 00:45:42 <sebersole> just trying to make sure that part is all working Aug 31 00:46:32 <sebersole> pretty sure the first case is not overly difficult to account for, ust trying to fathom this second case.. Aug 31 00:48:32 <stliu_> readwritecache Aug 31 00:48:42 <stliu_> sebersole, ^^ Aug 31 00:48:50 <sebersole> stliu_: yep, ^^ Aug 31 00:52:09 <sebersole> epbernard: tbh, i am looking back at these tutorials and I am not see all that much that really requires having the source code "there" Aug 31 00:52:25 <sebersole> *maybe* the first usage of Session Aug 31 00:53:37 <sebersole> *maybe* the hbm.xml for the date property Aug 31 00:54:15 <sebersole> i mean really looking at it Aug 31 00:55:00 <epbernard> sebersole: yes but you know hibernate very well and tutorials are for dummies (no offence, just stating a state) Aug 31 00:55:18 <epbernard> so seing what your code will look like makes a big difference Aug 31 00:56:11 <sebersole> i think i am being pretty objective Aug 31 00:56:23 <sebersole> and i have actually asked some users :) Aug 31 00:56:45 <sebersole> they find the callout-ed code blocks we use over-the-top Aug 31 00:56:55 <sebersole> thats been pretty consistent Aug 31 00:58:00 <sebersole> so rather than broad "we need code, I'm just suggesting we actually look at it and decide (judiciously) where Aug 31 00:58:51 <sebersole> like i cannot see any benefit to fragments from the hibernate.cfg.xml file Aug 31 00:58:59 <sebersole> how is that anything but fluff Aug 31 00:59:34 <sebersole> the entity? eh, again, why. its a bland boring java bean Aug 31 11:13:44 <sebersole> stliu_: you need any guidance on that case? Aug 31 11:13:55 <sebersole> about to drop off Aug 31 11:14:03 <stliu_> sebersole, yeah, please Aug 31 11:15:23 <stliu_> sebersole, i mean the guidance :D Aug 31 11:17:20 <sebersole> you have specific questions? Aug 31 11:18:18 <stliu_> i dont sure where to apply the entityentry's state you mentioned Aug 31 11:19:52 <sebersole> in the refresh event listener Aug 31 11:20:40 <sebersole> it sort of depends on its status Aug 31 11:20:48 <sebersole> what is the status on the refresh? Aug 31 11:21:05 <sebersole> it was flushed, so MANAGED? Aug 31 11:21:08 <stliu_> loading Aug 31 11:21:39 <sebersole> before the refresh listener sets it to that i mean Aug 31 11:21:55 <sebersole> it'll either be SAVING or MANAGED Aug 31 11:22:13 <stliu_> yeah Aug 31 11:22:22 <sebersole> well which? ;) Aug 31 11:22:30 <sebersole> its a very important distinction Aug 31 11:24:02 <stliu_> it is managed Aug 31 11:25:14 <sebersole> ugh Aug 31 11:28:17 <sebersole> essentially we need a way to identify entities which were created in this current transaction, and we dont have that in either case here Aug 31 11:29:33 <sebersole> i quick hack would be to keep a journal of the EntityKeys created on the PC and clear it on transaction completion Aug 31 11:30:31 <stliu_> sebersole, i also looked org.hibernate.engine.TwoPhaseLoad.initializeEntity(Object, boolean, SessionImplementor, PreLoadEvent, PostLoadEvent) Aug 31 11:31:03 <sebersole> tbh, i wonder if we have the same issue with generated properties Aug 31 11:31:11 <stliu_> i'm wondering is it possible to use a AfterTransactionCompletionProcess instead of put to cache after load immediately Aug 31 11:31:42 <sebersole> god lor no Aug 31 11:32:09 <sebersole> what does that buy you anyway? Aug 31 11:32:17 <sebersole> you'd still do the put Aug 31 11:33:33 <stliu_> but we can check if the tx success Aug 31 11:34:16 <sebersole> then how do you propse to stop other sessions from writing that data to cache? Aug 31 11:35:37 <sebersole> i think you are trying to "fix it up on the back end" Aug 31 11:35:56 <sebersole> the problem is not the put into the cache on refresh Aug 31 11:36:22 <sebersole> the problem is that we lose sight of the fact that this entity was just inserted and is not permenant yet Aug 31 11:37:48 <stliu_> is it only just inserted? what about updated Aug 31 11:38:39 <sebersole> in 99% of cases when we read data from a result set it is safe to assume it is persistent data (as in released from dbs transaction log) Aug 31 11:39:13 <sebersole> well in your first use case thats simply not a concern Aug 31 11:41:34 <sebersole> stliu_: did you try this first case with generated properties? Aug 31 11:41:48 <stliu_> yes, i did Aug 31 11:41:53 <sebersole> and? Aug 31 11:42:13 <stliu_> the current test case i'm using is with a generated property Aug 31 11:42:14 <stliu_> @Generated(GenerationTime.ALWAYS) Aug 31 11:42:14 <stliu_> @Column(columnDefinition="bigint default '1'") Aug 31 11:42:14 <stliu_> private Long price; Aug 31 11:42:33 <stliu_> same behavior Aug 31 11:47:37 <sebersole> so probably these 2 cases (refresh and generation) need to be handled specially in terms of putting into the cache Aug 31 11:48:24 <sebersole> though, tbh, i dont see how property-generation does the same incorrect thing Aug 31 11:49:19 <sebersole> it simply reads the generated state and rebuilds the "state to cache" prior to ever calling the cache Aug 31 11:54:43 <stliu_> yes, but when do it with refresh, internally it uses twophaseload to load the entity, and with in this class, it performs the cacheing Aug 31 11:55:38 <sebersole> [22:42] <stliu_> same behavior Aug 31 11:55:52 <sebersole> i asked if property generation worked or failed Aug 31 11:55:59 <sebersole> you said it had the same behavior Aug 31 11:56:25 <stliu_> the property generation worked but the test case fails Aug 31 11:56:39 <sebersole> um, huh Aug 31 11:57:20 <sebersole> does property generation suffer from this same thing? Aug 31 11:58:00 <stliu_> no, actually not much relates to property generation Aug 31 11:58:39 <sebersole> i have no idea what that means Aug 31 11:59:44 <stliu_> i know the refresh is for property generation Aug 31 12:01:06 <stliu_> this bug does not releates to the property generation code probably Aug 31 12:01:34 <stliu_> like you said, the data is not permenant yet, see case 2 Aug 31 12:01:43 <sebersole> stliu_: look at it like this... Aug 31 12:02:06 <sebersole> your first use case is really a property generation use case Aug 31 12:02:27 <sebersole> and propertu generation works as designed and as it is supposed to Aug 31 12:02:31 <sebersole> so... Aug 31 12:02:52 <sebersole> doesnt it make sense to have this use case operate more like that> Aug 31 12:03:14 <sebersole> i mean thats just a high level swag Aug 31 12:03:28 <sebersole> but that seems pretty logical/reasonable right? Aug 31 12:03:33 <stliu_> yes Aug 31 12:04:34 <sebersole> the problem there is that we lose the "context" there on the entity entry Aug 31 12:05:05 <sebersole> such that when we come back into it for the refresh we have no idea that we just inserted or updated it in this txn Aug 31 12:05:36 <sebersole> to me, thats the issue Aug 31 12:05:43 <stliu_> yes, agree Aug 31 12:06:10 <sebersole> delaying putting reads from the database into the cache until commit it not a resolution Aug 31 12:06:32 <sebersole> anyway, all that is for the refresh case Aug 31 12:06:42 <sebersole> the clear case is different Aug 31 12:07:12 <sebersole> tbh, not sure what we would do there Aug 31 12:07:19 <stliu_> yes, i think you're right :) Aug 31 12:07:37 <stliu_> that will make lots of changes, right Aug 31 12:07:51 <sebersole> stliu_: depends on how it is done Aug 31 12:09:43 <sebersole> even if we fixed it, property generation is far more efficient Aug 31 12:10:01 <sebersole> i mean sounds like bitching just for the sake of bitching Aug 31 12:10:54 <sebersole> i can get to it late wed or into thursday Aug 31 12:11:16 <sebersole> but really see above Aug 31 12:11:25 <stliu_> okay， thanks Aug 31 12:12:47 <sebersole> stliu_: i mean as of now, perhaps the only *real* solution s to invalidate the corresponding second level cache entries on clear Aug 31 12:17:16 <sebersole> if you clear the session of entities that were inserted or updated during this transaction we for the cache entires to invalidate after trasaction Aug 31 12:17:41 <sebersole> on fail, that is Aug 31 12:17:50 <sebersole> since we simply do not know Aug 31 12:18:50 <sebersole> eventually i can see a "gatekeeper" for the second level cache Aug 31 12:19:17 <sebersole> one per session i mean Aug 31 12:20:16 <sebersole> it could keep track of keys added for various operations Aug 31 12:20:27 <sebersole> and on rollback do some clean up Aug 31 12:20:46 <stliu_> will it cause other concurrent sessions see the dirty data before the *insert* session's tx complete/rollback? Aug 31 12:21:08 <sebersole> it wont do anything different than what it does right now Aug 31 12:21:19 <sebersole> in terms of putting stuff into the cache Aug 31 12:21:52 <sebersole> but for example, when we ask the gatekeeper to do delegate an insert... Aug 31 12:22:07 <sebersole> org.hibernate.cache.access.EntityRegionAccessStrategy#insert Aug 31 12:22:19 <sebersole> it'll keep track of that key Aug 31 12:22:33 <sebersole> and the fact that it was inserted during the current transaction Aug 31 12:23:54 <sebersole> when it sees the "put from read" it can see that the same key was also added via insert previously Aug 31 12:24:07 <sebersole> really its just doing some journaling Aug 31 12:24:11 <sebersole> so that... Aug 31 12:24:32 <sebersole> if/when the txn rollbacks back we know that we need to invalidate said key Aug 31 12:25:27 <sebersole> another option is to make it smart in terms of how and when it releases the cache puts Aug 31 12:25:55 <sebersole> aka in the above case, we already have the cache entry in place from the insert Aug 31 12:26:16 <sebersole> we could delay the put from read until successful transaction completion Aug 31 12:26:35 <sebersole> stliu_: make sense? Aug 31 12:26:40 <stliu_> this is what i was looking for? Aug 31 12:26:47 * ?// :Unknown command Aug 31 12:26:55 <stliu_> s/?// Aug 31 12:26:55 <sebersole> no you wanted to delay all puts Aug 31 12:27:04 <sebersole> oh ok Aug 31 12:27:25 <sebersole> but yes, that is a lot of work Aug 31 12:27:32 <sebersole> either way Aug 31 12:28:47 <sebersole> anyway, off to bed Aug 31 12:28:51 <sebersole> night all -- 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