Re: [ojb-users] Performance and other stuff

[Thomas M. <tho...@ho...>]

Hi Jan,

Jan Agermose wrote:

 > I'm looking into taking our java programming to the "next level". When
 > implementing our model layer (as in MVC) we typically do something like:
 >  class P {
 > 	public void setValues(ResultSet set) {
 > 		.. set variables from JDBC set
 > 	}
 > 	public void save() {
 > 		if (isnew) insert() else update();
 > 	}
 > 	public void insert() {
 > 		.. JDBC insert stuff
 > 	}
 > 	public void update() {
 > 		.. JDBC update stuff
 > 	}
 > }
 >
 > class locateP {
 > 	public P getById(id)
 > 	public Collection getBySomeOther(Other)
 > 	... lots of other ways to instantiate P
 > }
 >
 > This is a really simple way to do things
 >
 > 1. its simple and can be auto generated from the database schema - fast
 > development!
 > 2. using jdbcpool to optimize performance is simple
 > 3. SQL :-)
 > but
 > 1. no caching


IMHO caching is not *always* a must. there are many scenarios where
caching is rather a burden.


 > 2. two calls to a method in locateP will return to different instances
 > 	of the same object - due to no caching


A cache is *one* way to solve this. But: The real thing you are looking
for is transactional isolation accross threads (or even accross multiple
VMs). OJB can help you here.


 > X. all the problems that arise because of 2.
 >
 > So will OJB help me out here? mostly web applications!!


sure, lot's of people are running web-apps with OJB.


 > standalone mode:
 >
 > A: if I have one instance of the Database


???


 > 	A1: I will have shared instances of objects because its one 		database
 > one cache
 > 	A2: but what about performance? I have a cache, yes, but still 		all
 > communication with the database is done using -one- 		connection. Is
 > that a problem?


with OJB you work with multiple brokers. each broker holds its own
connection. We don't have connection pooling, we have broker pooling.
the OJB broker architecture is thread-safe.


 >
 > B: One Database object to each Thread or maybe even better one Database
 > per session


are you talking about an org.odmg.Database? or what else do you mean by
"one Database per sesion"?


 > 	B2: The performance should be better than A?
 > 	B1: but no shared instance of object?
 >
 > client/sever mode:
 >
 > C: is that any different than B?
 >


yes, C/S mode is about running OJB in a cluster accross multiple JVMs.


 > Maybe all my troubles are due to my understanding of shared instances of
 > objects -



 > should I say object identity?

yup !


 >
 > DB --- server cache --- client A
 >                     --- client B
 >
 > if client A and B query the same Object instance P (having id = 10) they
 > will end up getting 20 instances due to serialization. How will OJB help
 > me getting A's committed data into B?
 >


If you are using the OJB ODMG APi you have pessimistic locking that
provides a full tx isolation even in client/server mode.


 > And if I make a query for instance P having id = 10 and then a query for
 > a collection of P's that all so contains P (id = 10) - will the to
 > instances of P (id=10) be the same object (in memory) meaning that an
 > update to one will be reflected in the other?


this depends on the tx isolation level you choose.


 >
 > I know this is a lot to answer but I really need to understand this in
 > order to make a decision to go for OJB (or any other framework).
 >



HTH,

Thomas


 > Thanks in advance.
 >
 > Jan Agermose
 >
 >
 >
 > _______________________________________________________________
 >
 > Have big pipes? SourceForge.net is looking for download mirrors. We 
supply
 > the hardware. You get the recognition. Email Us: 
ban...@so...
 > _______________________________________________
 > Objectbridge-users mailing list
 > Obj...@li...
 > https://lists.sourceforge.net/lists/listinfo/objectbridge-users
 >
 >
 >
 >