I assume you mean "what entity state is loaded", not "what entities are loaded"?
So when you say "unflushed updates to entities" what *exactly* is it that you have in mind? When you say it is the diff b/w session and db, I envision pulling db snapshots and comparing against those. Or are you literally talking EntityUpdateAction ActionQueue entries? -----Original Message----- From: Gavin King Sent: Wednesday, October 04, 2006 10:05 AM To: Steve Ebersole Cc: hibernate-dev@lists.jboss.org Subject: Re: new SPI for EJB3/Seam Right, that's what I thought. My proposal is quite different. It says we don't care about remembering what entities are loaded. ------------------------- ----- Original Message ----- From: Steve Ebersole To: Gavin King Cc: 'hibernate-dev@lists.jboss.org' <hibernate-dev@lists.jboss.org> Sent: Wed Oct 04 07:40:42 2006 Subject: RE: new SPI for EJB3/Seam No it is slightly different. The distinction (it sounds like) being that replication was being built around transaction lifecycle (or that was the discussion at the time anyway). So what we discussed was the ability to get a changeset made up of added/removed entities as well as a "delta" of managed entities. Essentially this is what you are proposing as well, it sounds like to me; the distinction being what the delta is based on. In what Ben and I talked about, we discussed the delta in relation to the entities "loaded state". So assuming at least read-committed isolation we should be talking about approximately the same thing (depending on how reattached entities are handled) because replication was only happening on transaction boundaries. So I assume what you are talking about happens in line with the JSF lifecycle events? -----Original Message----- From: Gavin King Sent: Monday, October 02, 2006 10:57 AM To: Steve Ebersole Cc: 'hibernate-dev@lists.jboss.org' Subject: RE: new SPI for EJB3/Seam Note that my changeset is the diff b/w the session and the database, not the diff b/w the session at various points in time. Is that what you meant? -----Original Message----- From: Steve Ebersole Sent: Monday, October 02, 2006 7:26 AM To: Gavin King Cc: hibernate-dev@lists.jboss.org Subject: RE: new SPI for EJB3/Seam LOL, this is essentially exactly what I proposed with the JBossCache folks for efficient clustering. One additional thing though that I proposed was the ability to explicitly specify when to clear the collected changeset and re-collecting. -----Original Message----- From: Gavin King Sent: Saturday, September 23, 2006 8:27 AM To: Steve Ebersole Cc: hibernate-devel@lists.sourceforge.net Subject: new SPI for EJB3/Seam For truly efficient clustering of extended persistence contexts in the context of Seam or EJB3, we need a way to propagate unflushed changesets. What we need is an SPI like this: Serializable changeset = session1.getChangeSet(); session2.applyChangeSet(changeset); where session2 is an empty session, or perhaps even a session with some of the same entities as session1. The only state that needs to be sent in the changeset is new entities, unflushed updates to entities and deletions of entities. Steve, WDYT?
<<winmail.dat>>
_______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
