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

Steve Ebersole steve.ebersole at jboss.com
Wed Oct 4 13:59:24 EDT 2006


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 at 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 at lists.jboss.org' <hibernate-dev at 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 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?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/ms-tnef
Size: 3642 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/hibernate-dev/attachments/20061004/03fc37b5/attachment.bin 


More information about the hibernate-dev mailing list