I'd recommend using the cache even though it is being invalidated pretty quick the way
I described setting it up. The main advantage of using the cache in my mind is that
it prevents me from having to do a lot of coordination within my own code to avoid
last one wins scenarios within a single transaction. Let's take a simple example:
public void main(String[] args)
{
PersistenceBroker broker = PersistenceBrokerFactory.defaultPersistenceBroker();
broker.beginTransaction();
// retrieve the Article with the key '42' twice
Object[] pk = new Object[] {new Long(42)};
Identity id = new Identity(Article.class, pk);
Article a = (Article) broker.getObjectByQuery(new QueryByIdentity(id));
Article b = (Article) broker.getObjectByQuery(new QueryByIdentity(id));
doSomething1(a, broker);
doSomething2(b, broker);
broker.commitTransaction();
broker.close();
}
public void doSomething1(Article article, PersistenceBroker broker)
{
article.setName("My article");
broker.store(article);
}
public void doSomething2(Article article, PersistenceBroker broker)
{
article.setStock(56);
broker.store(article);
}
With the cache turned off the changes from doSomething1() would be overwritten by the
changes from doSomething2() even though they're occurring in the same transaction.
The reason is that the broker will return a new instance each time so a and b are
different instances based off the same row in the database.
This is a pretty artificial example but it's pretty easy to get yourself in a
situation where different parts of your code are stomping on each other.
I like the idea of a main cache like you're describing for performance. I don't know
of a transaction-safe version of this in OJB so far though (that's not to say there
isn't one). I've also seen hints of what you described with different VM's
synchronizing their caches against each other in ObjectCacheJCSImpl, but I didn't
follow it far enough to see exactly how it worked.
-----Original Message-----
From: Thomas Phan [mailto:[EMAIL PROTECTED]
Sent: Monday, March 17, 2003 1:05 PM
To: OJB Users List
Subject: Re: OJB conf with N servlets engines, and 1 DB
hi lance,
cool, it's exciting to see ur idea :)
i'm not sure if i get this correctly. in the servlet environment, a new
thread is created and died per request. for a simple servlet code, such as a
simple query, if the cache will get refreshed quickly, should we consider
not to use a cache at all (since the cache gets invalidated so quick, and
always get data directly from the database to fill the new cahce)?. OR
there's a main cache for the process' address space, and each thread will
get its own copy, then uses its copy to update against the main cache? if
such main cache exists, that cache should be shared among VMs on different
machines.
will there be a OJB internal protocol that synchronize different VMs' cache?
i.e. for all update, and delete queries, refresh other VM's caches. of
course, there maybe a simply centralized register to coordinate the VMs.
i get ur point about the optimistic lock, i agree with ur suggestion. as
long as the cache will be synchronized, some of my tables has a field to
lock it for a single user to write, like a check in/out. and i allow "last
win" in some other cases
nice to know that the SequenceManagerHighLowImpl algorithm gives unique keys
in a distributed environment :)
thanks
----- Original Message -----
From: "Lance Eason" <[EMAIL PROTECTED]>
To: "OJB Users List" <[EMAIL PROTECTED]>
Sent: Tuesday, March 18, 2003 2:21 AM
Subject: RE: OJB conf with N servlets engines, and 1 DB
I just went through this exercise myself, so what I know:
- first off it is probably best to either pull the latest from CVS or wait
for 1.0 rc2. Armin recently did some significant refactoring of the caching
code and it is much improved
- in OJB.properties set
'ObjectCacheClass=org.apache.ojb.broker.cache.ObjectCachePerBrokerImpl' -
this will do two things it will give you a broker-specific cache so brokers
working at the same time on different threads won't step on each other and
it will also cause the cache to be refreshed each time a broker is retrieved
from the pool
- the way I use the brokers is to get a broker at the beginning of my web
request, use that broker for the duration of the request and then
commit/abort it at the end of the request and release it back to the pool.
In other words I don't hold on to brokers for long periods of time, this
helps scalability and means that the data in my cache doesn't get too stale.
- as long as you use ObjectCachePerBrokerImpl and use a dedicated broker
per request you shouldn't have to worry about synchronizing access to your
objects. You will however have to worry about OptimisticLockExceptions when
updating your objects. Unless you're comfortable with last one wins
semantics (which you shouldn't be for most apps), you should add timestamp
or integer columns to each of your tables to store a version number for the
record. In the field descriptor for this column add locking="true" to tell
OJB that this column is for optimistic locking. Your app should then be
prepared to handle OptimisticLockExceptions. Because I don't expect these
to happen often I reshow the same page with the updated data from the
database and an error message asking the user to resubmit their changes.
- any data I want to cache for extended periods of time, e.g. rarely
changed lookup tables, etc., I implement as a cache above OJB holding on to
the objects returned from OJB queries.
- finally for unique sequences just specify the High Low Sequence Manager
inside your jdbc-connection-descriptor and mark you're primary key
field-descriptors with primarykey="true" and autoincrement="true", OJB will
take care of the rest.
<jdbc-connection-descriptor ...lots of attributes...>
<sequence-manager
className="org.apache.ojb.broker.util.sequence.SequenceManagerHighLowImpl">
<attribute attribute-name="grabSize" attribute-value="20"/>
</sequence-manager>
</jdbc-connection-descriptor>
-----Original Message-----
From: Thomas Phan [mailto:[EMAIL PROTECTED]
Sent: Monday, March 17, 2003 11:52 AM
To: OJB Users List
Subject: OJB conf with N servlets engines, and 1 DB
Hi,
In a single web site + load-balanced/cluster environment, if I have more
than 1 servlet engines (different VMs/HTTP sessions), each runs an OJB
instance, and 1 shared database, what OJB mode should I configure to get the
data cached (clear for all dirty cache automatically), synchronized, and
obtain unique sequence?
Is that something like the C/S mode? but all HTTP requests go to the cluster
of PB servers (no PB clients will exist in this case?)
Thanks
Thomas
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
