[hibernate-dev] RE: new SPI for EJB3/Seam

[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 at 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 at 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 at 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?