RE: new SPI for EJB3/Seam
by Steve Ebersole
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(a)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(a)lists.jboss.org' <hibernate-dev(a)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(a)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(a)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(a)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?
19 years, 1 month
RE: new SPI for EJB3/Seam
by Steve Ebersole
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(a)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(a)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(a)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?
19 years, 1 month
