Hi David,
David Keyes wrote:
> Sorry to sound so demanding in my last message. Don't take the word
> "gaurantee" personally -- its context was algorithmic ;)
No problem, I just wanted to make sure that I don't end up in jail
because I'm claiming OJB supports several features :-)
> I guess what I'm
> worried about, and was asking about, are holes in a consistency algorithm.
> For example, two different OJB servers update the same object at the same
> time, and during their attempt to synchronize their caches, one cache gets
> whacked. The JMS docs have an excellent description of the problem, and why
> it is so difficult to solve.
Ok. The OJB approach is most simple. If server A has updated object X to
X' it *does not* tell server B to replace the B instance of X with X'.
So there can't be conflicts as the one you mention.
Instead OJB uses an invalidation approach. If server A has updated
object X to X' it does inform B to *remove* it's instance X.
This strategy avoids update collisions.
Please note: the cache invalidation mechanism is implemented *above* the
concrete cache implementations. have a look at
PersistenceBrokerImpl.invalidate():
/**
*
* removes the objects obj from the brokers internal cache and
* inform other caches in OJB cluster about invalidation.
*/
public void invalidate(Identity oid)
throws PersistenceBrokerException
{
// if running in servermode inform other caches
if (isRunningInServerMode())
{
// call all other servers in OJB cluster to remove Object
// from theirs caches
Iterator iter = getPool().getAllEntries();
while (iter.hasNext())
{
ServerEntry entry = (ServerEntry) iter.next();
PersistenceBrokerClient client =
new PersistenceBrokerClient(entry, getPBKey());
client.removeFromCache(oid);
}
}
// if running in singlevm mode simply remove from local cache
else
{
removeFromCache(oid);
}
}
>
> I know that lateral cache synchronization is an incredibly difficult thing
> to pull off.
I definitely agree ! That's why we keep things as simple as possible, to
avoid confusion.
It is important to understand that the cache does not do any
synchronization by itself. The ODMG transaction management is
responsible to trigger PB.invalidate on transaction commit for all
updated objects.
see o.a.ojb.odmg.TransactionImpl.commit()
> I suppose I will read some source code to see how you guys
> accomlish what you do... Thanks for your reply, and I appreciate the
> excellent software!
>
Thanks,
Thomas
> Dave
>
> -----Original Message-----
> From: Thomas Mahler [mailto:[EMAIL PROTECTED]]
> Sent: Friday, October 11, 2002 4:54 PM
> To: OJB Users List
> Subject: Re: OJB Distributed Caching
>
>
> Hi David,
>
> David Keyes wrote:
>
>>It is unclear to me from the OJB documentation whether the default
>>distributed caching mechanism in OJB guarantees consistency. For example,
>>if I have cache A and cache B, on separate JVMs, both hitting the same
>>database, does OJB guarantee consistency betwixt the two caches (assuming
>>that all configuration elements are identical an A and B)?
>>
>
>
> This is a tough question. OJB uses a cache invalidation mechanism. that
> is if OJB running cache A detects that an object X in A has been updated
> all other caches in the OJB cluster (in this case only B) are informed
> to remove X from to perform a proper sync with the DB on the next access
> to X.
>
> This mechanism is not implemented on the cache level, but is provided by
> methods at our PersistenceBroker kernel level.
>
> This mechanism works as long A can perform a remote call to B. If this
> is not possible (say because of a networking problem) the caches can't
> be synchronized.
> So if everything runs normal OJB can guarantee cache consistency. If
> something extraordinary happens (like a broken wiring or hub) OJB cannot
> guarantee anything!
>
> This is true for commercial solutions too !
>
>
>>I know that JCS does NOT guarantee lateral cache consistency. Hybernate
>>uses JCS, and therefore, since we need cache consistency accros clustered
>>environments, Hybernate is out.
>
>
> I don't know the Hibernate solution. OJB does provide several cache
> implemenation and also a JCS based one. As mentioned our solution is
> implemented above the cache level. Thus our cache synchronization also
> works with a JCS cache.
>
>
>>OJB documentation seems to suggest that it
>>maintains cache consistency but never specifically states that it can
>>guarantee it.
>
>
> Correct. What kind of guarantee do you expect? If you read the Apache
> license you will find the following part stating the legal situation:
>
> * THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED
> * WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
> * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
> * DISCLAIMED. IN NO EVENT SHALL THE APACHE SOFTWARE FOUNDATION OR
> * ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
> * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
> * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF
> * USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
> * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
> * OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT
> * OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
> * SUCH DAMAGE.
>
> cheers,
> Thomas
>
>
>
>
>
>>Thanks in advance.
>>
>>Dave Keyes
>>
>>--
>>To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
>>For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
>>
>>
>>
>>
>
>
>
> --
> To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
>
>
> --
> To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
>
>
>
>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
