Dan Hobbs <[EMAIL PROTECTED]> writes: > Currently, ALL the data is loaded from the (Oracle) database into > memory at login time, and held in so-called "Bean" objects (but I'm > not convinced that's a good name for them). References to these bean > objects are kept in session attributes. The data is then retrieved > from memory and the database is not touched after the initial > data-loading.
Beans is a Java specific term, ie: it means something specific to Java developers. It sounds to me like these objects _are_ beans. > The servlets are hosted by tomcat (just locally for the moment). The > intention is that they will be used by a few users, not even a > hundred, but must cope with more than one. Pretty low requirements, the situation you've been left with will be okay as long as there aren't too many rows. If I understand you correctly you've got a row->bean mapping, that's not necessarily a good thing but then neither is changing all the code. If you've got many rows and you're creating some in memory cache of what is in the SQL tables then that's probably not that good. But if the beans are all small self contained objects then an initialization synch with the SQL tables isn't that bad. > 1. The login mass data load is removed, and instead all the data > retrieval, instead of being from memory, is rewritten to use > prepared statements and get the data which would be better cached by > Oracle anyway than being read into memory. Any future update > statements (and selects which read from the relevant tables) would > have to be synchronized. This would be ok... you have XX problems though: i) a PreparedStatement owns a cursor and therefore a Connection. You could try and write a PS pool to allow you to share a small number of PS's across all your requests. That's often a useful trick but there is one catch to it, you're ResultSet must be closed at the end of the request (so you can check the free PS back into the pool). Some requirements don't easily facilitate that. ii) you're now doing many queries that possibly return the same data over and over. Depending on what you're doing this can be useless load, eg: you're returning the same query results to multiple people. There are ways round that (server side caching of resulting pages) but they're perhaps more tricky than just reading everything into memory and spitting it out a lot. > 2. We use Enterprise Java Beans. Firstly, this is all really new > stuff to me. I have read (I believe on this list) that Tomcat is not > an EJB container. Therefore I guess we would have to have some other > web application service running to act as the EJB container which > would persist throughout the life of the web server. Then the > Tomcat-delivered servlets would make calls to some session beans > (where would they be?) which would manipulate the data from the > entity beans which represent the database. This is not a good idea. EJB is an advanced architecture that is not suited to the kind of small application that (it sound like) you're dealing with. Interestingly, if you went down the EJB road, you'd end up with something that is not dissimilar to your current system; the EJB container would cache instances of the entity beans (which would presumably represent a table row) until you had something approaching the memory use you have now. > Option 1 sounds simpler to me, and I could start implementing that right > now, but before I go I want to make sure I am doing the right > thing! Personally, I'd stick with what you've got, unless you're having a problem or it won't scale to what you want to do. > I apologise if I have not explained something properly there. If > anyone can offer any advice then it would be greatly appreciated. I > can offer better explanation if needed. You were a *bit* vague and thus my response is a bit vague too... if you tell us _specifically_ what you're doing then we can help a bit more specifically /8-> Nic Ferrier ___________________________________________________________________________ To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff SERVLET-INTEREST". Archives: http://archives.java.sun.com/archives/servlet-interest.html Resources: http://java.sun.com/products/servlet/external-resources.html LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
