<?xml version="1.0" encoding="UTF-8"?>











<rss version="2.0" xmlns:jf="http://www.jivesoftware.com/xmlns/jiveforums/rss">



<channel>
    <title>Support Forums: Message List - Optimizing CMP EJB cache strategy in WebLogic</title>
    <link>http://www.theserverside.com</link>
    <description>Most recent forum messages</description>
    <language>en</language>
    
        <generator>Jive Forums Silver 5.5.30 (www.jivesoftware.com)</generator>
    
    <pubDate>Wed, 19 Jun 2013 10:40:40 -0400</pubDate>


    <item>

        <title>Best solution: stored procedures</title>
        <link>http://www.theserverside.com/discussions/thread.tss?thread_id=32900</link>

        

        
            <description><![CDATA[You really have long running, complicated transactions, which are not easy to rollback in the case of optimistic locking exception, and you really need better performance, I think the best solution is to implement in a stored procedure inside the DB....]]></description>
        

        <pubDate>Wed, 23 Nov 2005 08:26:31 -0500</pubDate>

        

        <jf:creationDate>Wed, 23 Nov 2005 08:26:31 -0500</jf:creationDate>
        <jf:modificationDate>Wed, 23 Nov 2005 08:26:31 -0500</jf:modificationDate>
        <jf:date>Nov 23, 2005</jf:date>
        <jf:author>Xenofon Grigoriadis</jf:author>
        <jf:replyCount>0</jf:replyCount>
    </item>


    <item>

        <title>Why Coherence is better?</title>
        <link>http://www.theserverside.com/discussions/thread.tss?thread_id=32900</link>

        

        
            <description><![CDATA[<blockquote>Still have hard time to justify why multicasting couple bytes of Object id in local segment could consume more network traffic than transferring whole object state (couple hunderd bytes usually) even to one node (usually two because of backup...]]></description>
        

        <pubDate>Fri, 01 Apr 2005 11:42:53 -0500</pubDate>

        

        <jf:creationDate>Fri, 01 Apr 2005 11:42:53 -0500</jf:creationDate>
        <jf:modificationDate>Fri, 01 Apr 2005 11:42:53 -0500</jf:modificationDate>
        <jf:date>Apr 1, 2005</jf:date>
        <jf:author>Cameron Purdy</jf:author>
        <jf:replyCount>0</jf:replyCount>
    </item>


    <item>

        <title>Why Coherence is better?</title>
        <link>http://www.theserverside.com/discussions/thread.tss?thread_id=32900</link>

        

        
            <description><![CDATA[<blockquote>I will never be able to convince you of something that you don't want to believe.</blockquote><br>You will be able to convince me easily by presenting logical explanations :-). I take your point about spreading load between multiple computers...]]></description>
        

        <pubDate>Fri, 01 Apr 2005 10:43:26 -0500</pubDate>

        

        <jf:creationDate>Fri, 01 Apr 2005 10:43:26 -0500</jf:creationDate>
        <jf:modificationDate>Fri, 01 Apr 2005 10:43:26 -0500</jf:modificationDate>
        <jf:date>Apr 1, 2005</jf:date>
        <jf:author>Dmitri Maximovich</jf:author>
        <jf:replyCount>1</jf:replyCount>
    </item>


    <item>

        <title>Why Coherence is better?</title>
        <link>http://www.theserverside.com/discussions/thread.tss?thread_id=32900</link>

        

        
            <description><![CDATA[<blockquote>I assume that you referring here to Distributed cache where each piece of data in the cache is held on only one cluster node.</blockquote><br><i>Owned</i> by one cluster node. Other nodes could also have the same data cached, but the owner...]]></description>
        

        <pubDate>Fri, 01 Apr 2005 07:00:36 -0500</pubDate>

        

        <jf:creationDate>Fri, 01 Apr 2005 07:00:36 -0500</jf:creationDate>
        <jf:modificationDate>Fri, 01 Apr 2005 07:00:36 -0500</jf:modificationDate>
        <jf:date>Apr 1, 2005</jf:date>
        <jf:author>Cameron Purdy</jf:author>
        <jf:replyCount>2</jf:replyCount>
    </item>


    <item>

        <title>Why Coherence is better?</title>
        <link>http://www.theserverside.com/discussions/thread.tss?thread_id=32900</link>

        

        
            <description><![CDATA[<blockquote>Multicast vs. point-to-point. If you have to multi-cast the id, it uses a fixed length packet no matter what. Multi-cast across the whole cluster vs. updating just the node that manages (owns) the value within the cluster and point-to-point...]]></description>
        

        <pubDate>Thu, 31 Mar 2005 20:51:41 -0500</pubDate>

        

        <jf:creationDate>Thu, 31 Mar 2005 20:51:41 -0500</jf:creationDate>
        <jf:modificationDate>Thu, 31 Mar 2005 20:51:41 -0500</jf:modificationDate>
        <jf:date>Mar 31, 2005</jf:date>
        <jf:author>Dmitri Maximovich</jf:author>
        <jf:replyCount>3</jf:replyCount>
    </item>


    <item>

        <title>Why Coherence is better?</title>
        <link>http://www.theserverside.com/discussions/thread.tss?thread_id=32900</link>

        

        
            <description><![CDATA[<blockquote>For invalidation you just need to transport object identifier of some sort vs transporting whole object state so how is that possible to use less network traffic in this case?</blockquote><br>e.g. Multicast vs. point-to-point. If you have to...]]></description>
        

        <pubDate>Thu, 31 Mar 2005 13:48:12 -0500</pubDate>

        

        <jf:creationDate>Thu, 31 Mar 2005 13:48:12 -0500</jf:creationDate>
        <jf:modificationDate>Thu, 31 Mar 2005 13:48:12 -0500</jf:modificationDate>
        <jf:date>Mar 31, 2005</jf:date>
        <jf:author>Cameron Purdy</jf:author>
        <jf:replyCount>4</jf:replyCount>
    </item>


    <item>

        <title>Why Coherence is better?</title>
        <link>http://www.theserverside.com/discussions/thread.tss?thread_id=32900</link>

        

        
            <description><![CDATA[<blockquote>Coherence can avoid the staleness issue altogether, and generally does so with less network traffic than WLS uses for non-reliable invalidation</blockquote><br>For invalidation you just need to transport object identifier of some sort vs...]]></description>
        

        <pubDate>Thu, 31 Mar 2005 13:35:35 -0500</pubDate>

        

        <jf:creationDate>Thu, 31 Mar 2005 13:35:35 -0500</jf:creationDate>
        <jf:modificationDate>Thu, 31 Mar 2005 13:35:35 -0500</jf:modificationDate>
        <jf:date>Mar 31, 2005</jf:date>
        <jf:author>Dmitri Maximovich</jf:author>
        <jf:replyCount>5</jf:replyCount>
    </item>


    <item>

        <title>Why Coherence is better?</title>
        <link>http://www.theserverside.com/discussions/thread.tss?thread_id=32900</link>

        

        
            <description><![CDATA[<blockquote>If WLS invalidating cache across the cluster already why would using Coherence is better option here?</blockquote><br>Coherence can avoid the staleness issue altogether, and generally does so with less network traffic than WLS uses for...]]></description>
        

        <pubDate>Thu, 31 Mar 2005 13:04:36 -0500</pubDate>

        

        <jf:creationDate>Thu, 31 Mar 2005 13:04:36 -0500</jf:creationDate>
        <jf:modificationDate>Thu, 31 Mar 2005 13:04:36 -0500</jf:modificationDate>
        <jf:date>Mar 31, 2005</jf:date>
        <jf:author>Cameron Purdy</jf:author>
        <jf:replyCount>6</jf:replyCount>
    </item>


    <item>

        <title>Why Coherence is better?</title>
        <link>http://www.theserverside.com/discussions/thread.tss?thread_id=32900</link>

        

        
            <description><![CDATA[Cameron,<br><br>If WLS invalidating cache across the cluster already why would using Coherence is better option here? From what I know about Coherence (not much) is that it could/would invalidate cache transitionally (I think it's debatable if this is...]]></description>
        

        <pubDate>Thu, 31 Mar 2005 10:47:01 -0500</pubDate>

        

        <jf:creationDate>Thu, 31 Mar 2005 10:47:01 -0500</jf:creationDate>
        <jf:modificationDate>Thu, 31 Mar 2005 10:47:01 -0500</jf:modificationDate>
        <jf:date>Mar 31, 2005</jf:date>
        <jf:author>Dmitri Maximovich</jf:author>
        <jf:replyCount>7</jf:replyCount>
    </item>


    <item>

        <title>There are no silver bullet</title>
        <link>http://www.theserverside.com/discussions/thread.tss?thread_id=32900</link>

        

        
            <description><![CDATA[The point of optimistic concurrency control is that the first time you run the transaction, you can use potentially stale data, and it doesn't muck up the database. Let me explain:<br><br>1. App is deployed on 2 servers<br>2. Server 1 runs a TX that...]]></description>
        

        <pubDate>Thu, 31 Mar 2005 08:06:41 -0500</pubDate>

        

        <jf:creationDate>Thu, 31 Mar 2005 08:06:41 -0500</jf:creationDate>
        <jf:modificationDate>Thu, 31 Mar 2005 08:06:41 -0500</jf:modificationDate>
        <jf:date>Mar 31, 2005</jf:date>
        <jf:author>Cameron Purdy</jf:author>
        <jf:replyCount>8</jf:replyCount>
    </item>


    <item>

        <title>There are no silver bullet</title>
        <link>http://www.theserverside.com/discussions/thread.tss?thread_id=32900</link>

        

        
            <description><![CDATA[I agree with Manuel, of course Optimistic locking is not always faster, everything is depends on your specific problem domain. By definition, locking is 'optimistic' because it assumes that lock collisions are rare which could or could not be true for...]]></description>
        

        <pubDate>Wed, 30 Mar 2005 09:52:22 -0500</pubDate>

        

        <jf:creationDate>Wed, 30 Mar 2005 09:52:22 -0500</jf:creationDate>
        <jf:modificationDate>Wed, 30 Mar 2005 09:52:22 -0500</jf:modificationDate>
        <jf:date>Mar 30, 2005</jf:date>
        <jf:author>Dmitri Maximovich</jf:author>
        <jf:replyCount>9</jf:replyCount>
    </item>


    <item>

        <title>Depends on the environment</title>
        <link>http://www.theserverside.com/discussions/thread.tss?thread_id=32900</link>

        

        
            <description><![CDATA[Its not really an absolute number, it depends more on what the code is doing, the database, the hardware it is running on, the network latency (if distributed) any several other factors. Its not a TPS limit, just a cross over threshold specific to an...]]></description>
        

        <pubDate>Wed, 30 Mar 2005 09:02:32 -0500</pubDate>

        

        <jf:creationDate>Wed, 30 Mar 2005 09:02:32 -0500</jf:creationDate>
        <jf:modificationDate>Wed, 30 Mar 2005 09:02:32 -0500</jf:modificationDate>
        <jf:date>Mar 30, 2005</jf:date>
        <jf:author>Manuel De Jesus</jf:author>
        <jf:replyCount>0</jf:replyCount>
    </item>


    <item>

        <title>Pessimistic locking can be faster</title>
        <link>http://www.theserverside.com/discussions/thread.tss?thread_id=32900</link>

        

        
            <description><![CDATA[<blockquote>When you get to higher transaction volumes (number depend on your hardware and configuration can be as low as 50 transactions per second</blockquote><br>How many TPS is considered high?]]></description>
        

        <pubDate>Wed, 30 Mar 2005 07:13:07 -0500</pubDate>

        

        <jf:creationDate>Wed, 30 Mar 2005 07:13:07 -0500</jf:creationDate>
        <jf:modificationDate>Wed, 30 Mar 2005 07:13:07 -0500</jf:modificationDate>
        <jf:date>Mar 30, 2005</jf:date>
        <jf:author>han theman</jf:author>
        <jf:replyCount>1</jf:replyCount>
    </item>


    <item>

        <title>Pessimistic locking can be faster</title>
        <link>http://www.theserverside.com/discussions/thread.tss?thread_id=32900</link>

        

        
            <description><![CDATA[When you get to higher transaction volumes (number depend on your hardware and configuration can be as low as 50 transactions per second), pessimistic update locking can be faster than optimistic detection.  In these scenario the recovery process for...]]></description>
        

        <pubDate>Wed, 30 Mar 2005 02:13:31 -0500</pubDate>

        

        <jf:creationDate>Wed, 30 Mar 2005 02:13:31 -0500</jf:creationDate>
        <jf:modificationDate>Wed, 30 Mar 2005 02:13:31 -0500</jf:modificationDate>
        <jf:date>Mar 30, 2005</jf:date>
        <jf:author>Manuel De Jesus</jf:author>
        <jf:replyCount>3</jf:replyCount>
    </item>


    <item>

        <title>It's all about quality of service you need</title>
        <link>http://www.theserverside.com/discussions/thread.tss?thread_id=32900</link>

        

        
            <description><![CDATA[Will,<br><br>I don't see no contradiction here, it's either your application need to detect concurrent updates or it doesn't. Basically you have a choice between three possible 'levels of isolation' if you want: <br><br>- No locking, no optimistic...]]></description>
        

        <pubDate>Tue, 29 Mar 2005 12:49:00 -0500</pubDate>

        

        <jf:creationDate>Tue, 29 Mar 2005 12:49:00 -0500</jf:creationDate>
        <jf:modificationDate>Tue, 29 Mar 2005 12:49:00 -0500</jf:modificationDate>
        <jf:date>Mar 29, 2005</jf:date>
        <jf:author>Dmitri Maximovich</jf:author>
        <jf:replyCount>4</jf:replyCount>
    </item>



</channel>
</rss>

