objectbridge-developers — public list for developer issues

[Objectbridge-developers] [SOS] SSH & CVS

[<tho...@it...>]

Hi all,

I'm still having trouble with WinCVS.

When I switch authorization to "passwd on server" I can login (with my
sourceforge account "thma") and checkout files from our CVS repository.
But when I try do update any file I get a message telling me that I don't
have write access to the repository.
Why do I have no write access?

Do I need SSH to write access permission ?

I installed cygwin and configured a public key for ssh. I also set 2
environment variables CVS_RSH and HOME. I extended my path to find ssh.
I can now start ssh from a dos box and log in to
cvs.objectbridge.sourceforge.net.

But when I set the WInCVS preferences to use SSH authentication I can't even
login to the repository. I get an error message:
"First set authentication in preferences". What does this message mean?

Do you have any ideas ??!!

Thanks for your help


Thomas

[Objectbridge-developers] ObjectSnapshot and CVS Stuff

[Dixon-Peugh, D. <Dav...@tp...>]

I've put my ObjectSnapshot code into CVS.

I've also put 

// $Log$

at the bottom of a lot of files.  So, we
should get the CVS log on most, if not
all files.

David.

[Objectbridge-developers] [FYI] interesting links

[<tho...@it...>]

Hi all,

I received an eMail from from Janno Kusman who supplied me with some very
interesting links.

>
>  http://www.joeyoder.com/papers/patterns/PersistentObject/Persista.pdf
>
>
> http://www.javaworld.com/jw-01-2000/jw-01-step_p.html
>
 http://red.ip.ee/~janno/opf/opf.jar

enJoy,

Thomas

[Objectbridge-developers] CVS Access

[Dixon-Peugh, D. <Dav...@tp...>]

Greetings,

I have just updated the "ojb" project in CVS with
all of the 0.1.17 code Tom has provided.

I also put some changes to the TransactionImpl, 
TransactionTable and TransactionPool into CVS too.

David.

RE: [Objectbridge-developers] OJB-0.1.17

[Dixon-Peugh, D. <Dav...@tp...>]

The TransactionTable class looks like it is backwards.

You have:

   Thread get( Transaction key_tx )

When I think it is supposed to be the other way around:

   Transaction get( Thread keyThread )

This way we can retrieve the Transaction associated with
the thread.  Additionally, as it is possible for another
thread to "join" a transaction, you aren't guaranteed to
have a single transaction associated with a single thread.

Tom, if you will take some time and put the source up in
CVS, then we will all be able to work with the code rather
than just pointing out oddities.

Thanks,

David.

-----Original Message-----
From: obj...@li...
[mailto:obj...@li...]On Behalf Of
Thomas Mahler
Sent: Wednesday, November 15, 2000 1:18 AM
To: 'obj...@li...'
Subject: [Objectbridge-developers] OJB-0.1.17


Dear ObJectBridge enthusiasts,

ojb-0.1.17 is out now!

New features:
- Using Identity Objects as lightweight placeholders(representing the
uniqueness of objects, credits to
David)
- Proxy support, configurable lazy materialization using Identity
objects
- Smart updates/inserts (see server sample, how users can interact with
this
mechanism, credits to Bill)

enJoy,

Thomas

Next things I'll will try:
- Connection pooling
- improved QBE facility
- Transaction handling

_______________________________________________
Objectbridge-developers mailing list
Obj...@li...
http://lists.sourceforge.net/mailman/listinfo/objectbridge-developers

[Objectbridge-developers] OJB-0.1.17

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

Dear ObJectBridge enthusiasts,

ojb-0.1.17 is out now!

New features:
- Using Identity Objects as lightweight placeholders(representing the
uniqueness of objects, credits to
David)
- Proxy support, configurable lazy materialization using Identity
objects
- Smart updates/inserts (see server sample, how users can interact with
this
mechanism, credits to Bill)

enJoy,

Thomas

Next things I'll will try:
- Connection pooling
- improved QBE facility
- Transaction handling

re: [Objectbridge-developers] Object Identities

[<tho...@it...>]

Hi David,

>
> First off, it is not necessary that we build the Identity
> object from the database.  It should be possible to build
> an Identity object by hand, from an XML document or from
> an HTML form.
>

good idea!

> This is important as it should not be possible to create
> the actual object from any place asside from its source.
> If a persistent object already exists, then you want to
> get it from the source to ensure that it is complete.
>
> Secondly, the introduction of Identities provides us with
> a nifty implementation of the ODMG collections.  We could
> build the internal collection with lightweight identity
> objects, and when references are made to "getObject" or
> what have you, we could return the actual object the identity
> represents.

In the last week I have been working on a proxy concept using your Identity
objects.
I'm suggesting exactly the same approach as you! I also developed a simple
demo application
I finished coding on this task yesterday and now am working on a new release
(i.e. new DOS- and SH-scripts to get things installed and running). I hpoe
to finish this today and will publish a new release on our Site. I will
inform you via eMail when I'm finished.
If you are where eager on getting the new code just tell, I will send you a
new tar.gz with working java code but without SH-scripts!


>
> Why would we want to use Identities instead of the actual
> objects?  First, all of our collections that we manage
> would be of the same type.  Second, as we provide the
> implementation of the Identity, we can do things to make
> it easier.  (Like provide Comparable interface to the
> Identities.)

I 'invented' a ProxyRsIterator that is used to build this kind of 'lazy'
collections

>
> Any chance we can get ObJectBridge into CVS so I can
> check in some code?

Jon has checked in the 0.1.9 release into CVS. So there should be no problem
in checking in your code!
(Unfortunately I'm to stupid to use WinCVS :-( )

regards,

Thomas

>
> Thanks,
>
> David.
>
> _______________________________________________
> Objectbridge-developers mailing list
> Obj...@li...
> http://lists.sourceforge.net/mailman/listinfo/objectbridge-developers
>

[Objectbridge-developers] Object Identities

[Dixon-Peugh, D. <Dav...@tp...>]

I was poking around with the idea of Object Identities
yesterday, and think I may have come accross some nice
features.

First off, it is not necessary that we build the Identity
object from the database.  It should be possible to build
an Identity object by hand, from an XML document or from
an HTML form.

This is important as it should not be possible to create
the actual object from any place asside from its source.
If a persistent object already exists, then you want to
get it from the source to ensure that it is complete.

Secondly, the introduction of Identities provides us with
a nifty implementation of the ODMG collections.  We could
build the internal collection with lightweight identity
objects, and when references are made to "getObject" or
what have you, we could return the actual object the identity
represents.

Why would we want to use Identities instead of the actual
objects?  First, all of our collections that we manage
would be of the same type.  Second, as we provide the
implementation of the Identity, we can do things to make
it easier.  (Like provide Comparable interface to the
Identities.)

Thirdly, we get all the benefits that Thomas has brought
up.  It allows lazy retrieval of the information.

Thoughts, comments?

Any chance we can get ObJectBridge into CVS so I can 
check in some code?

Thanks,

David.

[Objectbridge-developers] Re: [objectbridge - Open Discussion] RE: Cache Manager & RSIterator

[David Dixon-P. <dp...@mi...>]

Thomas,

If the Objects are maintaining Identity, then perhaps we should say that
explicitely in the code.

Lets create a class "Identity" which basically maintains:
    Class Name
    Primary Key values for an object

This class would have the following methods:
    getObject( boolean forWrite )
     releaseObject()

getObject will lazily load the entire object into memory, as well as handle
things such as locking.  This handles two problems at once:

As long as getObject() and releaseObject() are called consistently we
can manage the locks,  and guarantee such useful stuff as Read Consistency.

This would also act as your proxy in doing lazy evaluation.

The other thing this allows us, is to move the Object Building code out of
RsIterator and the PersistenceBroker, and only concentrate on making
Identities out of result sets.

Let me know what you think,

David.




no...@so... wrote:

> Read and respond to this message at:
> http://sourceforge.net/forum/message.php?msg_id=72106
> By: thma
>
> Hi David,
>
> You are right this is a bit ugly.
> One of my design goal was to maintain object identity (i.e. if two objects have
> the same PK values
> they are one and the same instance).
> When you are looking up a single object by its PK values this is simple: lookup
> the ObjectCaches
> hashtable and only load from db if nessesary.
> If you select multiple object with a multi-row resultset it's a bit more difficult.
> because each row does
> eventually represent an object that is already cached.
> To resolve these potential conflicts I chose a slow solution: build an object
> from the resultsets row,
> take the Objects pk field Vector to make a standard lookup using the persistence
> broker etc.
> If an Object is already cached the first loaded object is dicarded and the cached
> Version returned ==> allocation overhead
> If an Object is not yet cached the ObjectCache performs a second db Lookup,
> and the first object is discarded agein ==>
> even more overhead through double lookup.
>
> If it was this simple we might build a quick workaround but:
> The first loading by RsIterator does only fill the skalar fields of the object,
> whereas PersistenceBroker::getObjectByPk
> does a bit more, if loading is necessary it calls getDBObject which loads also
> References an Collections.
>
> of course you can copy all this logic right into RsIterator::getObjectFromResultSet
> but I don't like this kind of code doubling.
>
> three other approaches:
> 1. in RsIterator::getObjectFromResultSet don't fill all the objects skalar fields
> but only the pk values of the temporary
> object obj. This wil reduce Reflection overhead.
> 2. invent new methods in PersistenBroker which take the stubbed object obj as
> a additional parameter
> and try to fill it's reference and collection fields in order to reduce lookup
> overhead.
> 3. I'm dreaming of a proxy concept for the management of reference and collections.
> Such a concept would make direct interaction
> with the ObjectCache much saver. Why? if today an object is cached and any of
> its reference attributes
> has not been loaded the reference == null and the application developer has
> fill the reference attribute by own application code.
> Otherwise he will get null-pointer exceptions.
> If using Proxies the refernce attribute will hold a proxy object which is clever
> enough to do on demand lookup
> when client code accesses the attribute.
> I did not implement any proxy stuff in the PersistenceBroker phase because the
> PB should capable to persist
> arbitrary objects.
> But once we start with a transaction Manager, the client code needs a higher
> integration with the persistency framework
> an then its pretty ok to force the developer to use proxies and interface etc.
>
> --
>
> I set up a mailing list
> http://lists.sourceforge.net/mailman/listinfo/objectbridge-developers
> I think its a good idea to use this medium so everyone can participate in all
> discussion.
>
> regards,
>
> Thomas
>
> ______________________________________________________________________
> You are receiving this email because you elected to monitor this forum.
> To stop monitoring this forum, login to SourceForge and visit:
> http://sourceforge.net/forum/monitor.php?forum_id=43066

[Objectbridge-developers] Re:

[Jon G. <jga...@co...>]

Thomas wrote:
> Heiliger Bimbam, you know some German ?!

A little bit here and there of a few languages.

>I think ObjectBridge will be pretty slow and not very reliable compared to
>commercial product running for years.
>But OTO its not as difficult to use as all these monster products.

Sure. I expect the commercial developers to have faster-running products,
and also have better GUI's for editing the mappings in UML diagrams.

I'd be content to just provide some basic functionality. I was going to
start working on #21214 today.

> Agreed. Unfortunately I have no experience with CVS, so I'm looking for a
> volunteer to get it running

I can get it running on my machine, for sure. I think though for SourceForge
development, they host the CVS repository on their machine. I wonder how we
set that up?

Thanks for cc'ing to this list. I'd prefer using forums over mailing lists--
if the SourceForge forum software could accept email in addition to sending
out notification by it (which many commercial products do), that's in
effect, a "mailing list."

Jon

[Objectbridge-developers] Intelligent update

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

Hi all

here is a discussion about intelligent updates I hat with Bill:

>> [BILL:] I *think* that to do this [Intelligent Update] will require 
>> some cooperation on the part of
>> the user.   
> 
> 
> [THOMAS:] I aggree! There are approaches that use a preprocessor to 
> identify  setters in the user code to generate the necessary 
> state-management in  some OODB's. At least POET works this way.  but 
> using a preprocessor  does not fit well into the java world, I think.
> 
>> The least intrusive way that I can think of to do this is for
>> the persistable object to 1) contain some sort of StateManager 
>> object, which we provide;
>> 2) update that StateManager object any time a setXXX method is executed
>> on the persistable object.
> 
> 
> I've included my latest snapshot. You will find a working example for 
> using the "ODMG-Server" in ojb.examples.server.App.
> Studying my code will show you that all access to persistent object 
> has to be within a Transaction.
> The TransactionImpl is responsible for tracking which persistable 
> objects have been newly created, loaded from the RDBMS or have been 
> touched by any setter-methods.
> This is necessary for the transaction in order to do the right thing 
> with each persistable object on commit or rollback.
> To accomplish this tracking the TransactionImpl maintains a hashtable 
> with objects  (namely their identity hash) as keys and 
> ModificationState-objects as values.
> This is very close to your suggestion of a StateManager per each 
> object. Only difference: I would prefer to not keep the  StateManager 
> within the object, but in a hash table. One of my design goals is to 
> keep coupling of user code and our framework at a minimum !
> 
> My ModificationStates applies two design patterns: State and Command.
> Here comes the State pattern:
> When you start with reading an object from the RDBMS (as in 
> ojb.examples.server.Article::getArticleByPk(...)) your resulting 
> object will be marked with the state StateOldClean (Old = already in 
> RDBMS, Clean = unmodified).
> All setters have to call method markModified() which results in a call 
> to TransactionImpl::markModified(object) where the state-transition 
> method ModificationState::markDirty() is called to return the 
> resulting new Modification state of  our object. In this example the 
> State will change to StateOldDirty. See StateOldClean::markDirty().
> 
> Here comes Command:
> When it comes to commiting or aborting the transaction, each objects 
> ModificationState is used to execute the proper action for each object.
> some examples:
> if an old object is clean there's no use of  writing it to the DB on 
> commit(). But if it is marked OldDirty we need an UPDATE !
> if a newly created object has been marked for deletion, there's no use 
> of executing a DELETE on commit(), as the object is not stored in the 
> DB yet.
> All new objects that have not been marked for deletion need an 
> INSERT-statement on commit.
> On transaction commit the ModificationState::commit() is excuted for 
> each state in the transactions ObjectStateTable. As class 
> ModificationState is abstract, the semantics of commiting and aborting 
> a given state is defined in the concrete state classes.
> 
>> 
>> I've attached two source files wich illustrate my thinking on this; both
>> of them are in the ojb.examples.broker package on my machine:
>> 1) StateManager.java -- initialized with the number of fields in the
>> containing object, then uses bitmasking to keep track of the state of
>> each of these fields; also has a boolean isModified() method that
>> returns true if at least one field has been modified, or false if no
>> modifications were made (use in tx manager?);
> 
> 
> I think we can add your StateManager functionality (tracking which 
> fields have been modified) to my ModificationState class.
> The algorithm is elegant and much faster than all my java reflection 
> stuff.
> the markModified-Method needs a parameter that reaches fieldname or id 
> to the ModificationState.
> 
>> 2) GranularUpdateTest.java -- has several fields that would be mapped to
>> db columns; contains a StateManager object; each setXXX accessor method
>> calls StateManager.updateState( field id number ); contains sample test
>> code in the main method.
>> 
>> I mention in comments in the code that perhaps the FieldDescriptor id,
>> which is the same as the field id that the setXXX methods need to pass
>> to the StateManager, could be looked up in the xml repository ...
> 
> 
> Yes there's a method FieldDescriptor::getColNo() which returns the id 
> from the xml-file.
> 
>> 
>> My idea is this: we can still persist arbitrary objects, but they will
>> have to use the old style update (writing all instance variables to the
>> db);
> 
> 
> Very important point! The original PersistenceBroker should be kept as 
> generic as possible.
> 
>>  however, if someone wants to simply include the StateManager object
>> and the updateState calls in their accessors, we can intelligently
>> construct an update statement on only those fields that have been
>> modified.
> 
> 
> Exactly, TransactionImpl has to track all modifications of objects and 
> thus has all relevant knowledge to generate intelligent SQL code.
> If you have a look  at PersistenceBrokerImpl::store(Object) you will 
> see how "stupid" this generic approach is when we want to use it from 
> our server:
> It creates and executes a select statement to check whether the object 
> is in the RDBMS already, in order to decide whether INSERT or UPDATE 
> is needed.
> Our server knows if an object is already in the DB by a look at its 
> ModificationState: if its a StateOldXXX we just need an UPDATE.
> And by including your tracking of field modification we can generate 
> very lean "SET FIELD = VALUE" clauses.
> 
>> Caveat: this is all off the top of my head this morning, so if this does
>> not mesh with the direction you have in mind, I'll gladly withdraw the
>> idea   ;->
> 
> 
> I think we have similar ideas how to address this update thing. Of 
> course you could not know that I was working on related things in the 
> server package already.
> 
>> I've done Swing gui coding, and did produce a gui to help with an O/R
>> mapping package at a previous employer.  That package didn't use xml,
>> but I'd be interested in trying to come up with something for this.  
> 
> 
> Your experience might be very helpful here !
> 
>> If
>> someone else who loves gui coding joins the project, though , I wouldn't
>> object to letting him/her do it ...
> 
> 
> Same for me...
> But maybe its to early to address this gui tool. In my opinion we have 
> to concentrate on the basic concepts first. Maybe there will still be 
> a lot of changes to the repository format during the process. I think 
> we can shift this task to one of the late stages of our project.
> 
regards,

Thomas

> 

[Objectbridge-developers] Re: ObjectBridge

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

Hi David,

thanks for the code ! will have a look at it soon. did you my reply on your remarks
the "stupid" code in RsIterator ?

please set obj...@li... in cc so that all can
participate.

best regards, Thomas

David Dixon-Peugh wrote:

> Thanks for putting me on the ObJectBridge project.
>
> I went in and put some notes about one of the tasks you had listed.  (I can't
> remember what exactly the task was, but I do remember my solution for it.)
>
> I'm including source code for ThreadIterator which basically is an iterator
> which contains two additional methods (addObject and finish).
>
> The way you use this, is you loop through one iterator, and call addObject
> on the ThreadIterator.  This then queues it up for use by the other thread.
>
> This will allow you to know exactly when it is okay to get rid of a database
> connection.
>
> There is another variation to this that we may want to try, and that is creating
> a PreFetchIterator.  PreFetchIterator is a seperate thread which will pull
> from the provided Iterator until it is done.
>
> To solve the problem of reclaiming the resources, it is possible to provide a
> "watch" parameter, which will be notified at the end of the PreFetch when
> it is possible to clean up the resources.
>
> Here are some examples of how I think this might work (using fork, because
> it is easier to see here.)
>
> -------------- ThreadIterator -----------------
>
> ThreadIterator ti = new ThreadIterator();
>
> if (fork()) {
>   return ti;
> } else {
>   while (RS.next()) {
>     ti.addObject( makeFromRS( RS ) );
>   }
>   ti.finish();
>   // Clean up code. . .
> }
>
> -------------------------------------------
>
> Or, with the PreFetch, we could do something like
>
> Object watch = new Object();
> PreFetchIterator pfi = new PreFetchIterator( rsi, watch );
> pfi.start();
>
> if (fork()) {
>    return pfi;
> } else {
>     try {
>       watch.wait();
>     } catch (InterruptedException e) { }
>     // Clean up code. . .
> }
>
> --------------------------------------------
>
> Obviously,  we would need to push and pull a few things here
> and there to get something that works.  I personally think that
> PreFetchIterator may be the way to go.  (Origionally, I was thinking
> ThreadIterator)
>
> There are many other things that could be going on that we could do
> while some other thread is handling pulling results, and serving them
> to the user.  Of course, this isn't BeOS, so creating a lot of threads
> is not necessarily a good thing.
>
> Well, enjoy the code. . . I'll try to do more work tommorow.  Maybe
> I'll check out what other tasks you have, and take a closer look
> at ojb.server.
>
> Thanks,
>
> David.
>
>   ------------------------------------------------------------------------
> package ojb.broker.accesslayer;
>
> import java.util.Iterator;
> import java.util.NoSuchElementException;
> import java.util.LinkedList;
> import java.lang.InterruptedException;
>
> /**
>  * ThreadIterator contains a thread-safe
>  * queue which implements the Iterator class.
>  *
>  * The idea is, that you execute database
>  * operations in a different thread, and
>  * return this Iterator right away.
>  *
>  * The database thread adds stuff onto the
>  * end of the queue, and the calling thread
>  * pulls stuff off of the begining of the
>  * queue.
>  *
>  * The calling thread will block until data
>  * is available from the queue.
>  *
>  * @author <a href="mailto:dp...@mi...">David Dixon-Peugh</a>
>  */
>
> public class ThreadIterator implements Iterator {
>
>     private boolean isDone = false;
>     private LinkedList queue = new LinkedList();
>
>     public ThreadIterator() { }
>
>     public void addObject( Object obj ) {
>         synchronized (queue) {
>             queue.addLast( obj );
>         }
>         queue.notifyAll();
>     }
>
>     public void finish() {
>         isDone = true;
>         queue.notifyAll();
>     }
>
>     public boolean hasNext() {
>         while (true) {
>             synchronized (queue) {
>                 if ( queue.size() > 0 ) {
>                     // If I have data in the Queue, return True.
>                     return true;
>                 }
>                 if (isDone) {
>                     return false;
>                 }
>             }
>             try {
>                 queue.wait();
>             } catch (InterruptedException e) { }
>
>         }
>     }
>
>     public Object next()
>         throws NoSuchElementException
>     {
>         while (true) {
>             synchronized (queue) {
>                 if (queue.size() > 0 ) {
>                     return queue.removeFirst();
>                 }
>                 if (isDone) {
>                     throw new NoSuchElementException();
>                 }
>             }
>             try {
>                 queue.wait();
>             } catch (InterruptedException e) { }
>         }
>     }
>
>     public void remove()
>     {
>         while (true) {
>             synchronized (queue) {
>                 if (queue.size() > 0 ) {
>                     queue.removeFirst();
>                     return;
>                 }
>                 if (isDone) {
>                     return;
>                 }
>             }
>             try {
>                 queue.wait();
>             } catch (InterruptedException e) { }
>         }
>     }
> }
>
>   ------------------------------------------------------------------------
> package ojb.broker.accesslayer;
>
> import java.util.Iterator;
> import java.util.NoSuchElementException;
> import java.util.LinkedList;
> import java.lang.InterruptedException;
>
> /**
>  * PreFetchIterator is an iterator which is based on
>  * another iterator.  However, this one runs in its
>  * own thread.
>  *
>  * You can build it with one of two constructors.
>  *
>  * The first constructor takes only the Iterator to
>  * be prefetched.
>  *
>  * The second constructor takes the Iterator and a
>  * generic object.  This Object will have "notify"
>  * called on it when the PreFetching is done.
>  *
>  * This way the builder of the iterator can call
>  * wait() and wake up when the resources of the
>  * iterator are used.
>  *
>  * @author <a href="mailto:dp...@mi...">David Dixon-Peugh</a>
>  */
>
> public class PreFetchIterator
>     implements Iterator, Runnable {
>
>     private Object w;
>     private Iterator src;
>     boolean isDone = false;
>
>     private LinkedList queue = new LinkedList();
>
>     public PreFetchIterator(Iterator source)
>     {
>         src = source;
>         w = new Object();
>     }
>
>     public PreFetchIterator(Iterator source, Object watch) {
>         src = source;
>         w = watch;
>     }
>
>     /**
>      * From Runnable Interface
>      *
>      * This is basically a loop which pulls things from the
>      * source, and drops them into the queue.
>      *
>      * When the loop is done, it will call notifyAll on the
>      * watcher.
>      */
>
>     public void run() {
>         while (src.hasNext()) {
>             synchronized (queue) {
>                 queue.addLast( src.next() );
>                 queue.notifyAll();
>             }
>         }
>         isDone = false;
>         queue.notifyAll();
>         w.notifyAll();
>     }
>
>     /**
>      * From Iterator interface
>      *
>      * This checks to see if anything is on the queue,
>      * and if so, it returns true.
>      *
>      * If the queue is empty, and isDone is marked, then
>      * it is completed.
>      *
>      * Otherwise, it waits on the queue to be notified.
>      */
>
>     public boolean hasNext() {
>         while (true) {
>             synchronized (queue) {
>                 if ( queue.size() > 0 ) {
>                     // If I have data in the Queue, return True.
>                     return true;
>                 }
>                 if (isDone) {
>                     return false;
>                 }
>             }
>             try {
>                 queue.wait();
>             } catch (InterruptedException e) { }
>
>         }
>     }
>
>     public Object next()
>         throws NoSuchElementException
>     {
>         while (true) {
>             synchronized (queue) {
>                 if (queue.size() > 0 ) {
>                     return queue.removeFirst();
>                 }
>                 if (isDone) {
>                     throw new NoSuchElementException();
>                 }
>             }
>             try {
>                 queue.wait();
>             } catch (InterruptedException e) { }
>         }
>     }
>
>     public void remove()
>     {
>         while (true) {
>             synchronized (queue) {
>                 if (queue.size() > 0 ) {
>                     queue.removeFirst();
>                     return;
>                 }
>                 if (isDone) {
>                     return;
>                 }
>             }
>             try {
>                 queue.wait();
>             } catch (InterruptedException e) { }
>         }
>     }
> }

[Objectbridge-developers] Re:

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

Hi Jon,


> Guten Morgen!

Heiliger Bimbam, you know some German ?!

> I just discovered the domain of O-R Mapping the other week while
> evaluating some EJB modeling tools. I was disappointed that none the leading
>
> tools (Rational Rose, WebGain StructureBuilder) generated the obvious code
> given the DB schema.  At least WebGain pointed me to CoCoBase, where I
> learned about O-R Mapping. Knowing that name, I was able to do a search on
> SourceForge and pinpointed to one project-- yours! Just my lucky day, you
> are just starting on this. I'd like to help, to at least cut my teeth on
> this new field.

Welcome to the wonderful world of O/R mapping :-)

> I know that my company is willing to spend the money on commercial software,
>
> but it should be desirable to have this for open-source projects as well.

I'm working in a large IT-Company as a consultant in a J2EE prototyping
project. (We have to build a working ground architecture for other projects
that will build real world solutions). As one of the most important tasks we
have identified the Persistence issue. We will do an indepth study of all kind
of commercial products (Avantis Unisuite, CoCobase Versant VEC, Persistence
Powertier, Toplink, IBM VAP). Of course we will also have a look at
ObJectBridge. Using the already running PersistenceBroker with Bean Managed
Persistence entity beans should be quite straightforward.
I'm really interested in seeing the results of performance benchmarks.
I think ObjectBridge will be pretty slow and not very reliable compared to
commercial product running for years.
But OTO its not as difficult to use as all these monster products.

All people who have some experience with such tools tell me that they are
quite a burden in your development cycle and that some/most of them do not
work well.

>
> I have downloaded the sources and will look through. I don't think you've
> set up the CVS yet. Now that you have multiple developers, that would be a
> good thing.
>

Agreed. Unfortunately I have no experience with CVS, so I'm looking for a
volunteer to get it running

>
> Jon

Jon Garfunkel wrote:

> Thomas-
>
> I got it running. Cool. I didn't see the note informing that I needed
> jdk-1.2, so of course I got all sorts of errors when I ran it in 1.1
> first.
>

Sorry, I will have to place it at some more prominent place in the README.html
!

>
> I was wondering if you can add a piece to your to do list (and add me as a
> developer) to do automated mapping generations, based on the structure of
> the database. I'm going to start working on it.

Done !

I set up a developer mailing list:
http://lists.sourceforge.net/mailman/listinfo/objectbridge-developers
please subscribe this list, so that we all can share the content of individual
discussions.

best regards, beste Güße,

Thomas

[Objectbridge-developers] Cache Manager & RSIterator

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

>                By: dpeugh ( David Dixon-Peugh ) 
>                  Cache Manager & RSIterator [ reply ]   
>                2000-Nov-03 17:08 
>                Your Cache Manager implementation is very slick. I've been thinking 
>                about how to implement this type of caching in Java, and all I can 
>                say is you've got the right thing going here. 
> 
>                I found something in RSIterator.getObjectFromResultSet( ... ) that is a little 
>                confusing. Here is how I see the logic. 
>                New instance of the class is created. 
>                This instance gets its fields populated from the data values in the ResultSet 
>                The Primary Key fields are passed from the Instance to the PersistanceBroker 
> 
>                PersistanceBroker looks in the cache, and if it doesn't find one, goes to the 
>                database to pick up a new object. 
> 
>                What I'm wondering though, is why the instance that gets created from the 
>                ResultSet is discarded if it isn't in the cache. Is there someway of saving us 
>                from the extra database call to rebuild an object which should be there? 
> 
>                Or are we intentionally just writing queries which return the Primary Key. (If 
>                so, we can reduce the amount of reflections in executing a query.) 
> 
>                Thanks, 
> 
>                David. 
> 
> 
Hi David,

You are right this is a bit ugly.
One of my design goal was to maintain object identity (i.e. if two
objects have the same PK values
they are one and the same instance).
When you are looking up a single object by its PK values this is simple:
lookup the ObjectCaches
hashtable and only load from db if nessesary.
If you select multiple object with a multi-row resultset it's a bit more
difficult. because each row does
eventually represent an object that is already cached.
To resolve these potential conflicts I chose a slow solution: build an
object from the resultsets row,
take the Objects pk field Vector to make a standard lookup using the
persistence broker etc.
If an Object is already cached the first loaded object is dicarded and
the cached Version returned ==> allocation overhead
If an Object is not yet cached the ObjectCache performs a second db
Lookup, and the first object is discarded agein ==>
even more overhead through double lookup.

If it was this simple we might build a quick workaround but:
The first loading by RsIterator does only fill the skalar fields of the
object, whereas PersistenceBroker::getObjectByPk
does a bit more, if loading is necessary it calls getDBObject which
loads also References an Collections.

of course you can copy all this logic right into
RsIterator::getObjectFromResultSet but I don't like this kind of code
doubling.

three other approaches:
1. in RsIterator::getObjectFromResultSet don't fill all the objects
skalar fields but only the pk values of the temporary
object obj. This wil reduce Reflection overhead.
2. invent new methods in PersistenBroker which take the stubbed object
obj as a additional parameter
and try to fill it's reference and collection fields in order to reduce
lookup overhead.
3. I'm dreaming of a proxy concept for the management of reference and
collections. Such a concept would make direct interaction
with the ObjectCache much saver. Why? if today an object is cached and
any of its reference attributes
has not been loaded the reference == null and the application developer
has fill the reference attribute by own application code.
Otherwise he will get null-pointer exceptions.
If using Proxies the refernce attribute will hold a proxy object which
is clever enough to do on demand lookup
when client code accesses the attribute.
I did not implement any proxy stuff in the PersistenceBroker phase
because the PB should capable to persist
arbitrary objects.
But once we start with a transaction Manager, the client code needs a
higher integration with the persistency framework
an then its pretty ok to force the developer to use proxies and
interface etc.

--

I set up a mailing list
http://lists.sourceforge.net/mailman/listinfo/objectbridge-developers
I think its a good idea to use this medium so everyone can participate
in all discussion.

regards, Thomas