Thomas Mahler wrote:
Hi again Max,
<snip>
OJB manages the locking of lazy objects and Collection by a deferred locking
mechanism.
We are not using database mechanism for locking (e.g. row level locking) but
our own LockManager mechanism.
We are not using any JVM locking or synchronization mechanisms!
EH!!? Huh! explain please ;) How can you synchronize/lock in memory without
locking or synchronization mechanisms ?!
You are right, we do the lock management with a pluggable component called LockManager.
I just wanted to say that we are not relying on java *language* features like synchronized blocks.
So - how do you synchronize without it ? If you are not using language features, what are you using ? The database ?
As I understand it, OJB handles it by doing locking in JVM but this changes the
database transaction isolation semantics
You are right, OJB is able to provide Isolation levels for Object Transactions that are completely independ of the database transaction isolation!
And that is BAD from our view ;)
It's totally ok that OJB want to provide this feature,
but it really requires expert usage to use and is not simple and safe per default.
I think separating object level transactions from underlying db transactions is one of the greatest features in OJB!
In my view: A nice feature but not a necessity. (but again I think we hit what is different between Hibernate and OJB ....Hibernate wants to be good at storing/retreiving stuff form a RDBMS mainly through jdbc/sql... OBJ want's to be good at everything persistable....two different views, two different goals and two different solutions. People just need to be aware of this - many times people just want to store stuff in a RDMS and start use OJB's advanced/complex stuff even though they don't need it (and where I think Hibernate fits best)...and similar people uses Hibernate for high level object transactions yada yada where it does not fit in well.
By doing this you can treat transactions as normal objects and transport complete transactions (with all affected objects) from one JVM to another. You could even store a snapshot of a complete transaction in the DB. after sone time you can reactivate it and continue it.
Well - ain't that "just" a serialization of the java objects representing the "transaction" ?
How will you do this if object transactions are tightly coupled with jdbc resources?
We don't ;) .... but remember that our Session concept does not need to be bound by a JDBC transaction - it is just recommended. A session can be disconnected and reconnected to a Connection - and that is very usefull when using the session as a "work-holder".
Yes - and we also much more prefer optimistic locking than use database level locking
(but we support both and we think the database is much better to perform synchronization
of data than any client-side synchronization)
The LockManager is not necessarily a client side component. It can well be a server side component. This archtitecure works well even for the largest object oriented datastores: http://www.slac.stanford.edu/slac/media-info/20020412/database.htmlhttp://www.slac.stanford.edu/slac/media-info/20020412/database.html.
By client-side I meant client in respect to the database - not in respect to OJB.
The OJB solution does scale well. The LockManager implementation is very simple and so the overhead is not a problem.
Well - the ODMG implementation is much slower than the PB Api in your own tests, right?
The Hibernate core's speed is comparable to the PB API + small overhead when using locking...
and that is faster in the OJB ODMG implementation....so somewhere there is a bigger overhead somewhere ;)
OJB/ODMG is not yet as fast as we would like it to be, granted. We have found several performance hotspots so far. But AFAIK they were not related to the lockmanagement.
Ok - but lockmanagement is not the only thing that complicates ODMG ;)
cu, Thomas
later, Max
Our LockManager architecture uses the same concepts as the lock service of
highly scalable OO databases like Objectivity.
cu, Thomas
> There is also no way to clear cache
other than nullifing the Session which also leads to the
lazy collection
problem above. This is all probably not a problem if you
load and release
all data, including lookup data, with each use case e.g.
unit of work.
I was also dissapointed that there is no mechanism to
synchronize the cache with recent commits;
Is that not what session.refresh() is for ?
(or do you want a session wide refresh() method? - that would be slow!?!)
another reason you always have to
close the Session because it's the only way to remove stale
cache and get up
to date db data.
Again - you could use e.g. session.clear() for removing stale data...
Thanks for the comments and best regards, Max
-----Original Message----- From: Mahler Thomas [mailto:[EMAIL PROTECTED] Sent: Monday, November 17, 2003 4:53 AM To: 'OJB Users List' Subject: RE: Persistence frameworks
Hi Max,
Hi!
Just want to ask/clarify some stuff on this one - sorry for the late "answer" ;)
Happily:
OJB provides much more flexibility in caching; provides
object-space
transactions in a non-managed environment (if you are
running in a J2EE
container which provides JTA than this is probably a wash
as you will
probably want to use JTA for transactions and both OJB and
Hibernate
support using JTA);
May I ask what object-space transactions you mean OJB provides that
Hibernate does not ? (Is it the ODMG stuff you are
referring to, which
requires extra tables in the db ?)
The three high-level APIs (ODMG, JDO and OTM) provide full
object level
transaction management. They provide a full instance
life-cycle model as
specified by the JDO spec.
By using JTA these tx managers can be integrated into J2EE
containers or
other JTA compliant tx managers.
The ODMG implementation *does not* require any additional tables
in general!
- If you want to use special persistent collections (DList,
DMap, etc) you
must provide additional tables to hold these entities.
(AFAIK Hibernate does currently not provide support for the ODMG
persistent
collections. I'm pretty sure that once you start to implement
them you will
end up in providing some tables to hold their data...)
- If you want to run OJB/ODMG on a cluster you need an additional
lock table
in the DB which is used to synchronize transactions across
the cluster.
<snip>
The biggest thing is a core design difference where OJB is designed to be very flexible and allow you to get exactly
what you need
whereas Hibernate is designed to do it one way and make
that one way
match what most people need.
Yes - that's probably the biggest difference between OJB and Hibernate. Hibernate want KISS, OJB want ultimate flexibility ;)
My impression is that this was true some time ago, but you are
adding a lot
of pluggable features into Hibernate these days (Field
access strategies,
Cache implementations, etc.). I don't believe that a KISS approach works for a heavy duty O/R tool. Users work in so many different environments with so many different requirements... So IMO best thing to do is to design for ultimate flexibility
from scratch.
Finally, the licensing issue is either a
huge difference or a doesn't-matter depending on your
company's lawyers
and/or how you intend to distribute the application -- OJB is ASL Hibernate is LGPL.
Just remember to read of license faq which states that Hibernate can be used in any project commercially or not - and without making your project opened source!
The only "limitations" is that you cannot fork Hibernate (write ya' own persistence engine) and that if you make some improvements to hibernate you should submit them back to the project.
IMO this *is* a limitation! OJB was build to allow users to write
their own
persistence engines by reusing our code-base. Apart from
providing object
orient persistence API's it's also meant as a construction kit for persistence layers.
On the other hand Hibernate provides two things that OJB
does not -- a
forthcoming book
There are already several books available that have a
decent coverage of
OJB. (e.g. http://www.amazon.com/exec/obidos/ASIN/0596003285/qid%3D1054656123
/sr%3D2-1/ ref%3Dsr%5F2%5F1/102-4902036-7120135 and
http://www.amazon.com/exec/obidos/tg/detail/-/1861007817/qid=1 054655953/sr=8
-1/ref=sr_8_1/102-4902036-7120135?v=glance&s=books&n=507846).
A book exclusive covering OJB is also under discussion.
and the ability to easily hand it a JDBC Connection and
have it use that Connection (this can be done via some voodoo-like runtime configuration of OJB, but isn't a good idea --
Of course OJB allows you to provide your own connection
lookup mechanism.
It would take about 5 Minutes to write a ConnectionManager
implementation
that can work with user connections. Until today nobody
requested this
feature...
According to Clark's law "sufficiently advanced technology is
indistinguishable from magic"
(http://c2.com/cgi/wiki?ClarkesLaw). But the
OJB metadata and configurtaion framework applies patterns
that are known for
ages and covered by tons of textbooks
(http://c2.com/cgi/wiki?MetaObjectProtocol,http://c2.com/cgi/w iki?TheArtOfTh
eMetaObjectProtocol). So calling it voodoo is really giving
to much credit
to OJB ;-)
OJB pretty much
needs to know the JNDI lookup for your DataSource in its
configuration).
ok - did not knew that. I seem to remember using OJB before without requiring any kind of JNDI!?
Correct, JNDI is not mandatory, it's an option.
cheers, Thomas
Just my 2 cents ;)
/max
------------------------------------------------------------
---------
---------------------------------------------------------------------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]
--------------------------------------------------------------------- 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]
