Most of your data integrety issues should be resolved by proper use of Transactions.
Make sure that your updates are Transactional.
The easiest way to do this is put the
JDBC work in an EJB and set the transaction-attribute in the ejb-jar.xml.
Check your setting for Isolation Level (in the weblogic-ejb-jar.xml. If it is, for example, READ_COMMITED, then your reads will not see uncommited (partial) data from the updates.
I don't suggest using SERIALIZABLE with Oracle as it does not actually serialize, but uses optimistic locking - you'll get rollbacks and exceptions if you have concurrent users updating the same data.
For the reads, you have a couple of choices. You can do a database call everytime you need a piece of data. This could give you different answers for the same data item (or incinsistent results for related items) if an update happens between the two reads.
Another way to go is to do one bulk (transactional) read at the beginning of the
servlet or at the beginning of the user's session. Get all the data you might need and shove it into the HTTP session. You won't see intermediate updates, but all the data will be consistent.
The right answer is probably somewhere in the middle of these two, and depends on the application (and, as always, involves making compromises between development effort, concurency, load, user experience, likelyhood of problems, etc).
If you put your database access behind Entity Beans using CMP, then WLS will let you configure lots of caching options, so you can go thru the entities without having to implement database caching of your own.