5:08 a.m.
dirty data be inserted into 2L cache
-------------------------------------
Key: HHH-5490
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5490
Project: Hibernate Core
Issue Type: Bug
Components: caching (L2)
Affects Versions: 3.6.0.Beta3, 3.5.5
Reporter: Strong Liu
{code}
public void testInsertWithRefresh() {
getSessions().getCache().evictEntityRegions();
getSessions().getStatistics().clear();
Session s = openSession();
s.beginTransaction();
Item item = new Item();
item.setName("stliu");
s.save(item);
s.flush();
s.refresh(item);
s.getTransaction().rollback();
s.close();
Map cacheMap = getSessions().getStatistics()
.getSecondLevelCacheStatistics("item").getEntries();
assertEquals(0, cacheMap.size());
s = openSession();
s.beginTransaction();
item = (Item)s.get(Item.class, item.getId());
s.getTransaction().commit();
s.close();
assertNull("it should be null", item);
}
{code}
see above test case, since the insertion is rollbacked, so, there is no that row in the
DB, but you can see the null assertion will fail due to the dirty data be inserted into
the 2l cache after refresh operation.
--
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
5:10 a.m.
New subject: [Hibernate-JIRA] Updated: (HHH-5490) dirty data be inserted into 2L cache
[
http://opensource.atlassian.com/projects/hibernate/browse/HHH-5490?page=c...
]
Strong Liu updated HHH-5490:
----------------------------
Attachment: ItemTest.java
Item.java
test case attached
dirty data be inserted into 2L cache
-------------------------------------
Key: HHH-5490
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5490
Project: Hibernate Core
Issue Type: Bug
Components: caching (L2)
Affects Versions: 3.5.5, 3.6.0.Beta3
Reporter: Strong Liu
Attachments: Item.java, ItemTest.java
{code}
public void testInsertWithRefresh() {
getSessions().getCache().evictEntityRegions();
getSessions().getStatistics().clear();
Session s = openSession();
s.beginTransaction();
Item item = new Item();
item.setName("stliu");
s.save(item);
s.flush();
s.refresh(item);
s.getTransaction().rollback();
s.close();
Map cacheMap = getSessions().getStatistics()
.getSecondLevelCacheStatistics("item").getEntries();
assertEquals(0, cacheMap.size());
s = openSession();
s.beginTransaction();
item = (Item)s.get(Item.class, item.getId());
s.getTransaction().commit();
s.close();
assertNull("it should be null", item);
}
{code}
see above test case, since the insertion is rollbacked, so, there is no that row in the
DB, but you can see the null assertion will fail due to the dirty data be inserted into
the 2l cache after refresh operation.
--
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
10:39 a.m.
New subject: [Hibernate-JIRA] Commented: (HHH-5490) dirty data be inserted into 2L cache
[
http://opensource.atlassian.com/projects/hibernate/browse/HHH-5490?page=c...
]
Strong Liu commented on HHH-5490:
---------------------------------
https://jira.jboss.org/browse/JBPAPP-4895
dirty data be inserted into 2L cache
-------------------------------------
Key: HHH-5490
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5490
Project: Hibernate Core
Issue Type: Bug
Components: caching (L2)
Affects Versions: 3.5.5, 3.6.0.Beta3
Reporter: Strong Liu
Attachments: Item.java, ItemTest.java
{code}
public void testInsertWithRefresh() {
getSessions().getCache().evictEntityRegions();
getSessions().getStatistics().clear();
Session s = openSession();
s.beginTransaction();
Item item = new Item();
item.setName("stliu");
s.save(item);
s.flush();
s.refresh(item);
s.getTransaction().rollback();
s.close();
Map cacheMap = getSessions().getStatistics()
.getSecondLevelCacheStatistics("item").getEntries();
assertEquals(0, cacheMap.size());
s = openSession();
s.beginTransaction();
item = (Item)s.get(Item.class, item.getId());
s.getTransaction().commit();
s.close();
assertNull("it should be null", item);
}
{code}
see above test case, since the insertion is rollbacked, so, there is no that row in the
DB, but you can see the null assertion will fail due to the dirty data be inserted into
the 2l cache after refresh operation.
--
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
11:49 p.m.
New subject: [Hibernate-JIRA] Assigned: (HHH-5490) dirty data be inserted into 2L cache
[
http://opensource.atlassian.com/projects/hibernate/browse/HHH-5490?page=c...
]
Strong Liu reassigned HHH-5490:
-------------------------------
Assignee: Steve Ebersole
dirty data be inserted into 2L cache
-------------------------------------
Key: HHH-5490
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5490
Project: Hibernate Core
Issue Type: Bug
Components: caching (L2)
Affects Versions: 3.5.5, 3.6.0.Beta3
Reporter: Strong Liu
Assignee: Steve Ebersole
Attachments: Item.java, ItemTest.java
{code}
public void testInsertWithRefresh() {
getSessions().getCache().evictEntityRegions();
getSessions().getStatistics().clear();
Session s = openSession();
s.beginTransaction();
Item item = new Item();
item.setName("stliu");
s.save(item);
s.flush();
s.refresh(item);
s.getTransaction().rollback();
s.close();
Map cacheMap = getSessions().getStatistics()
.getSecondLevelCacheStatistics("item").getEntries();
assertEquals(0, cacheMap.size());
s = openSession();
s.beginTransaction();
item = (Item)s.get(Item.class, item.getId());
s.getTransaction().commit();
s.close();
assertNull("it should be null", item);
}
{code}
see above test case, since the insertion is rollbacked, so, there is no that row in the
DB, but you can see the null assertion will fail due to the dirty data be inserted into
the 2l cache after refresh operation.
--
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
11:15 a.m.
New subject: [Hibernate-JIRA] Commented: (HHH-5490) dirty data be inserted into 2L cache
[
http://opensource.atlassian.com/projects/hibernate/browse/HHH-5490?page=c...
]
Strong Liu commented on HHH-5490:
---------------------------------
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
dirty data be inserted into 2L cache
-------------------------------------
Key: HHH-5490
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5490
Project: Hibernate Core
Issue Type: Bug
Components: caching (L2)
Affects Versions: 3.5.5, 3.6.0.Beta3
Reporter: Strong Liu
Assignee: Steve Ebersole
Attachments: Item.java, ItemTest.java
{code}
public void testInsertWithRefresh() {
getSessions().getCache().evictEntityRegions();
getSessions().getStatistics().clear();
Session s = openSession();
s.beginTransaction();
Item item = new Item();
item.setName("stliu");
s.save(item);
s.flush();
s.refresh(item);
s.getTransaction().rollback();
s.close();
Map cacheMap = getSessions().getStatistics()
.getSecondLevelCacheStatistics("item").getEntries();
assertEquals(0, cacheMap.size());
s = openSession();
s.beginTransaction();
item = (Item)s.get(Item.class, item.getId());
s.getTransaction().commit();
s.close();
assertNull("it should be null", item);
}
{code}
see above test case, since the insertion is rollbacked, so, there is no that row in the
DB, but you can see the null assertion will fail due to the dirty data be inserted into
the 2l cache after refresh operation.
--
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
12:23 p.m.
New subject: [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
dirty data be inserted into 2L cache
-------------------------------------
Key: HHH-5490
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5490
Project: Hibernate Core
Issue Type: Bug
Components: caching (L2)
Affects Versions: 3.5.5, 3.6.0.Beta3
Reporter: Strong Liu
Assignee: Steve Ebersole
Attachments: Item.java, ItemTest.java
{code}
public void testInsertWithRefresh() {
getSessions().getCache().evictEntityRegions();
getSessions().getStatistics().clear();
Session s = openSession();
s.beginTransaction();
Item item = new Item();
item.setName("stliu");
s.save(item);
s.flush();
s.refresh(item);
s.getTransaction().rollback();
s.close();
Map cacheMap = getSessions().getStatistics()
.getSecondLevelCacheStatistics("item").getEntries();
assertEquals(0, cacheMap.size());
s = openSession();
s.beginTransaction();
item = (Item)s.get(Item.class, item.getId());
s.getTransaction().commit();
s.close();
assertNull("it should be null", item);
}
{code}
see above test case, since the insertion is rollbacked, so, there is no that row in the
DB, but you can see the null assertion will fail due to the dirty data be inserted into
the 2l cache after refresh operation.
--
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
3:25 p.m.
New subject: [Hibernate-JIRA] Resolved: (HHH-5490) dirty data be inserted into 2L cache
[
http://opensource.atlassian.com/projects/hibernate/browse/HHH-5490?page=c...
]
Steve Ebersole resolved HHH-5490.
---------------------------------
Resolution: Fixed
Fix Version/s: 3.5.x
3.6.x
dirty data be inserted into 2L cache
-------------------------------------
Key: HHH-5490
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5490
Project: Hibernate Core
Issue Type: Bug
Components: caching (L2)
Affects Versions: 3.5.5, 3.6.0.Beta3
Reporter: Strong Liu
Assignee: Steve Ebersole
Fix For: 3.6.x, 3.5.x
Attachments: Item.java, ItemTest.java
Time Spent: 4.35h
Remaining Estimate: 0h
{code}
public void testInsertWithRefresh() {
getSessions().getCache().evictEntityRegions();
getSessions().getStatistics().clear();
Session s = openSession();
s.beginTransaction();
Item item = new Item();
item.setName("stliu");
s.save(item);
s.flush();
s.refresh(item);
s.getTransaction().rollback();
s.close();
Map cacheMap = getSessions().getStatistics()
.getSecondLevelCacheStatistics("item").getEntries();
assertEquals(0, cacheMap.size());
s = openSession();
s.beginTransaction();
item = (Item)s.get(Item.class, item.getId());
s.getTransaction().commit();
s.close();
assertNull("it should be null", item);
}
{code}
see above test case, since the insertion is rollbacked, so, there is no that row in the
DB, but you can see the null assertion will fail due to the dirty data be inserted into
the 2l cache after refresh operation.
--
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
4:46 a.m.
New subject: [Hibernate-JIRA] Commented: (HHH-5490) dirty data be inserted into 2L cache
[
http://opensource.atlassian.com/projects/hibernate/browse/HHH-5490?page=c...
]
Nikita Koksharov commented on HHH-5490:
---------------------------------------
Testcase will be broken if entity will use Transactional cache strategy!
dirty data be inserted into 2L cache
-------------------------------------
Key: HHH-5490
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5490
Project: Hibernate Core
Issue Type: Bug
Components: caching (L2)
Affects Versions: 3.5.5, 3.6.0.Beta3
Reporter: Strong Liu
Assignee: Steve Ebersole
Fix For: 3.5.x, 3.6.0.CR2
Attachments: Item.java, ItemTest.java
Time Spent: 4.35h
Remaining Estimate: 0h
{code}
public void testInsertWithRefresh() {
getSessions().getCache().evictEntityRegions();
getSessions().getStatistics().clear();
Session s = openSession();
s.beginTransaction();
Item item = new Item();
item.setName("stliu");
s.save(item);
s.flush();
s.refresh(item);
s.getTransaction().rollback();
s.close();
Map cacheMap = getSessions().getStatistics()
.getSecondLevelCacheStatistics("item").getEntries();
assertEquals(0, cacheMap.size());
s = openSession();
s.beginTransaction();
item = (Item)s.get(Item.class, item.getId());
s.getTransaction().commit();
s.close();
assertNull("it should be null", item);
}
{code}
see above test case, since the insertion is rollbacked, so, there is no that row in the
DB, but you can see the null assertion will fail due to the dirty data be inserted into
the 2l cache after refresh operation.
--
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
4:56 a.m.
New subject: [Hibernate-JIRA] Commented: (HHH-5490) dirty data be inserted into 2L cache
[
http://opensource.atlassian.com/projects/hibernate/browse/HHH-5490?page=c...
]
Nikita Koksharov commented on HHH-5490:
---------------------------------------
Please look here http://opensource.atlassian.com/projects/hibernate/browse/HHH-5690
dirty data be inserted into 2L cache
-------------------------------------
Key: HHH-5490
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5490
Project: Hibernate Core
Issue Type: Bug
Components: caching (L2)
Affects Versions: 3.5.5, 3.6.0.Beta3
Reporter: Strong Liu
Assignee: Steve Ebersole
Fix For: 3.5.x, 3.6.0.CR2
Attachments: Item.java, ItemTest.java
Time Spent: 4.35h
Remaining Estimate: 0h
{code}
public void testInsertWithRefresh() {
getSessions().getCache().evictEntityRegions();
getSessions().getStatistics().clear();
Session s = openSession();
s.beginTransaction();
Item item = new Item();
item.setName("stliu");
s.save(item);
s.flush();
s.refresh(item);
s.getTransaction().rollback();
s.close();
Map cacheMap = getSessions().getStatistics()
.getSecondLevelCacheStatistics("item").getEntries();
assertEquals(0, cacheMap.size());
s = openSession();
s.beginTransaction();
item = (Item)s.get(Item.class, item.getId());
s.getTransaction().commit();
s.close();
assertNull("it should be null", item);
}
{code}
see above test case, since the insertion is rollbacked, so, there is no that row in the
DB, but you can see the null assertion will fail due to the dirty data be inserted into
the 2l cache after refresh operation.
--
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
5001
days inactive
5068
days old
hibernate-issues@lists.jboss.org
8 comments
3 participants
participants (3)
-
Nikita Koksharov (JIRA) -
Steve Ebersole (JIRA)
-
Strong Liu (JIRA)