objectbridge-developers — public list for developer issues

[OJB-developers] Re: Wacky Question about JNDI

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

Hi Boris,

Thanks for your interest in OJB.

Boris Kuschel wrote:
> 
> This is probably stange to ask here but somehow
> appropriate.
> I need a general mechanism for persistence with
> load balancing support across Relational
> databases, which is supported here, 

May be there is some misunderstanding here:
OJB does support to have objects of different classes stored in
different relational databases.
OJB does NOT support a loadbalancing to store objects of the same class
in different RDBMS.

OJB does provide a loadbalancing on the OJB PersistenceBroker level.
This loadbalanicing does only affect the OJB middleware, but not the
backend databases!

>and for
> Directories as well.
> So my question is, is it possible to (easily)
> plug in JNDI support into this bridge? 


OJB does support JNDI lookup of datasources. But I guess that's not what
you are looking for?

If get you right you want a mechanism that allows you to store objects
either in an RDBMS or in a directory service. ANd then to retrieve
objects from this media transaparently for a client app?
That is your app for example just asks: give me all customer objects
where customer.address.city='London'.
The application does not see whether objects are stored in LDAP or in an
RDBMS.
Is this your requirement?

If so I have good news for you. My company has used the OJB
ojb.broker.query package to write a query adapter to LDAP that uses the
same query api as for RDBMS access!

I'm not sure about your load balancing requirements. You should provide
some more details on this

HTH,

Thomas

> I need a
> general mechanism for persistence with load
> balancing support and all thoses nifty things
> supported here.
> 
> Thanks for any help,
> 
> Boris Kuschel

Re: [OJB-developers] OJB relationships & more

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

Hi Christian,

I was on a short vacation so my answer is a bit late...

Christian Sell wrote:
> 
> Hello,
> 
> a few questions:
> 
> Q1: ======================================
> Even though database connection configuration is done in the
> JdbcConnectionDescriptor element, configuring of JNDI lookup for datasources
> must be done in OJB.properties with the ConnectionFactoryClass property (and
> the JdbcConnectionDescriptor/url.dbalias element is then "misused" as the
> jndi lookup name). I find that rather confusing. Why not have a a
> "jndi-lookup" element inside the JdbcConnectionDescriptor instead?
> 

That's a good idea! The JNDI based Connectionfactory was a quick hack to
get someone started using OJB within a J2EE environment. Thus it will
need some polishing...
I will put your request on my todo-list.

> Q2: ======================================
> according to the docs, OJB supports "lazy loading" of relationships through
> the proxy class mechanism. This means, that when an objects are loaded, for
> each loaded object and every to-N attribute a separate query is issued to
> retreive the foreign key attributes for the referenced objects. Later, when
> the referenced objects are accessed, each referenced object is loaded
> individually with a primary-key-query (I call this "singular loading"). This
> leads to the following scenario:
> 
> say, we have classes A, B, C. Class A has 2 collection attributes which
> point to B and C, respectively. B and C both have dynamic proxyies
> configured. Loading all instances of A would lead to the following
> processing sequence:
> 
> 1) perform "select * from TABLE_A".
> 2) Iterate the result set. For each row:
>     2.1) instantiate the A object
>     2.2) perform "select b.foreign_key from TABLE_A a, TABLE_B b where
> b.foreign_key = a.primary_key"
>     2.3) Iterate the result set. For each row:
>         2.3.1) instantiate the proxy and add to collection a_bs
>     2.4) perform "select c.foreign_key from TABLE_A a, TABLE_C c where
> c.foreign_key = a.primary_key"
>     2.4) Iterate the result set. For each row:
>         2.4.1) instantiate the proxy and add to collection a_cs
> 
> then, for each access to an object referenced through the collections a_bs
> or a_cs, another SQL statement would be issued. Now say we have 2 instances
> of A in the database, which both hold 20 references in each collection
> attribute. I was to access all objects in the above described data set, over
> time the number of SQL statement issued would be
> 
> 1 + number_of_collection_attributes + (number_of_collection_attributes *
> number_of_referenced objects),
> i.e. 1 + 2 + 2 * 20 = 43.
> 
> This loading scheme is extremely inefficient, especially since the number of
> statements issued increases linearily with the number of objects referenced
> (and accessed) in the collections. A smart JDBC programmer (or O/R tool)
> could handle all with 1 (!) outer join statement, or at most 3 statements.
> If I am right, I dont think the proxy mechanism increases efficiency a lot,
> since it only saves the object instantiation, but incurs a possibly
> 1000-fold increase of DBMS accesses.
> 

Of course, if you iterate over all elements of the B- and C-collections
Proxies are inefficient. It would make no sense to use proxies here, as
you know in advance that all objects in the collection attributes have
bo accessed.
Proxies can improve performance if only "some" of the Bs and Cs have to
be accessed.

> I think a lazy relationship loading mechanism must be implemented such, that
> it performs the foreign-key join query only when the relationship itself is
> accessed ("resolved").

In my proxy design I don't diffentiate between 1:1 references and 1:n
references. I will think of your idea to have special proxies for 1:n
attributes. 

 It should load the full object data (vs. only the
> foreign keys). 

I see one possible disadvantage of your solution here: Say we have your
proxies. Object A will then be created with two proxy attributes for the
B- and C-collection.
Now we have to access only the fourth element of the B-Collection.
According to you proxy mechanism all 20 B-objects contained in B are
instanciated on this access to the collection.

You will end up with 19 superfluous full instanciations versus 19
superfluous instanciations of Proxy objects with my existing concept.

For proxy classes, it should keep the raw data in a cache
> attached to the relationship, and instantiate from that cache. 

Maybe a tough problem as OJB proxies must be serializable due to the
client/server architecture.

>Everything
> else (especially singular loading) is unacceptable in a production
> environment.
> 

I will have a look at TopLink to see what they are doing here.

> Did I miss something?
> 
> Q3: ==================================
> I am wondering about the field/class ids in the repository.xml file. Why
> assign separate ids when the names would do just as well?
> 

Class ID's are superfluous. Field ID's are necessary to provide a order
relation for the Comparator used for sorting.
There will be a complete review and cleanup of the existing DTD once we
have included all 1.0 features to the existing DTD (n:m relationships,
automatic foreignkey assignment, JNDI naming)

> Q4: ==================================
> Are there any plans to remove the need for separately mapping foreign key
> attributes? I find this a rather annoying requirement, which clearly defeats
> the notion of "transparence".
> 

I'm not sure if I understand you right? 
Currently OJB requires to set foreign key attributes manually.
(E.G: we create a new A with 20 B objects in a collection attribute.
a.primary_key is computed automatically with the <autoincrement>
features. But we have to set the b.foreign_key attributes referencing to
a.primary_key manually.)
This is of course annoying and has to be replaced by some automatic
solution. This feature is already on the todo list. But I have not
started working on it.

> Of course I am willing to lend a hand in any of these matters
> regards,
> Christian
> 

Thanks,

Any help is appreciated a lot!


Thomas

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

[OJB-developers] Select count(x)

[Charles A. <cha...@hp...>]

Hello once more,

Is it possible to do a count() in an OQL expression ? Or rather, is it
possible to do a count() in OJB's implementation of OQL ?

As far as I can see, it isn't possible at the moment.

Basically, I'm trying to give an end user the ability to do a flexible
search that could return many hundred of rows; I need to be able to page the
results. I can get 'blocks' of objects quite simply (by skipping the first n
objects returned in a query) - but what I need to be able to do is to work
out how many blocks of results there are for the results of a query (but
without iterating the entire results), in order to display a paging-thing to
the enduser (A'la Google).

I'm sure this is a common requirement; I can think of other places where
count(n) would be useful, as well as max(), min() etc.

I can also see that putting functions into the OQL parser/query code could
be quite tricky, too. Is there any workaround anyone can think of ? I'm sort
of toying with the idea of creating a class that would create the 
select count(*) from x where xxx statement from the OQL query....

Cheers,

Charles.


This email and any attachments are strictly confidential and are intended
solely for the addressee. If you are not the intended recipient you must
not disclose, forward, copy or take any action in reliance on this message
or its attachments. If you have received this email in error please notify
the sender as soon as possible and delete it from your computer systems.
Any views or opinions presented are solely those of the author and do not
necessarily reflect those of HPD Software Limited or its affiliates.

 At present the integrity of email across the internet cannot be guaranteed
and messages sent via this medium are potentially at risk.  All liability
is excluded to the extent permitted by law for any claims arising as a re-
sult of the use of this medium to transmit information by or to 
HPD Software Limited or its affiliates.

[OJB-developers] OQLQueryImpl effieciency

[Charles A. <cha...@hp...>]

Hi all,

Whilst using OJB in a prototype, I found that using the standard
ojb.odmg.oql.OQLQueryImpl class to do an OQL query seemed a little
inefficient.

It turns out that this is because OQLQueryImpl uses a DList to return the
results as a collection. The DList implementation access the OJB_SEQ table
to gain an ID for itself, and one for each entry in the list. 

I have attached a quick-n-dirty try to improve on this; basically, I've
implemented a ManageableArrayList collection, which extends ArrayList and
implements ManageableCollection. I've also implemented a SpeedyQuery class,
which extends OQLQueryImpl and overrides execute to return a
ManageableArrayList instead of a DList. I've also attached a simple
CompareQueries class that tests the SpeedyQuery class.

In this test (against a table with 1889 rows on SQL server), the
OQLQueryImpl took on average 37 secs. The SpeedyQuery took 1.5 secs.

I'm sure there are drawbacks to this approach, and I'm sure that I've
overlooked something terribly important. The only things that I note at the
moment are :

* I'm not currently registering the resulting items with the current
transaction; this would be 
  trivial to achieve.
* If you remove or add an item to the ManageableArraylist, the changes would
not be propogated to 
  the database.

Still, even with those caveats (which I'm sure are possible to deal with), I
still think this speed improvement is not to be sniffed at. 

Comments are welcome; just be gentle with me - this is the first code I have
sent to an open-source mailing list....

With thanks,

Charles.


This email and any attachments are strictly confidential and are intended
solely for the addressee. If you are not the intended recipient you must
not disclose, forward, copy or take any action in reliance on this message
or its attachments. If you have received this email in error please notify
the sender as soon as possible and delete it from your computer systems.
Any views or opinions presented are solely those of the author and do not
necessarily reflect those of HPD Software Limited or its affiliates.

 At present the integrity of email across the internet cannot be guaranteed
and messages sent via this medium are potentially at risk.  All liability
is excluded to the extent permitted by law for any claims arising as a re-
sult of the use of this medium to transmit information by or to 
HPD Software Limited or its affiliates.


      

[OJB-developers] help

[Martin W. <Mar...@gm...>]

[OJB-developers] OJB relationships & more

[Christian S. <chr...@ne...>]

Hello,

a few questions:

Q1: ======================================
Even though database connection configuration is done in the
JdbcConnectionDescriptor element, configuring of JNDI lookup for datasources
must be done in OJB.properties with the ConnectionFactoryClass property (and
the JdbcConnectionDescriptor/url.dbalias element is then "misused" as the
jndi lookup name). I find that rather confusing. Why not have a a
"jndi-lookup" element inside the JdbcConnectionDescriptor instead?

Q2: ======================================
according to the docs, OJB supports "lazy loading" of relationships through
the proxy class mechanism. This means, that when an objects are loaded, for
each loaded object and every to-N attribute a separate query is issued to
retreive the foreign key attributes for the referenced objects. Later, when
the referenced objects are accessed, each referenced object is loaded
individually with a primary-key-query (I call this "singular loading"). This
leads to the following scenario:

say, we have classes A, B, C. Class A has 2 collection attributes which
point to B and C, respectively. B and C both have dynamic proxyies
configured. Loading all instances of A would lead to the following
processing sequence:

1) perform "select * from TABLE_A".
2) Iterate the result set. For each row:
    2.1) instantiate the A object
    2.2) perform "select b.foreign_key from TABLE_A a, TABLE_B b where
b.foreign_key = a.primary_key"
    2.3) Iterate the result set. For each row:
        2.3.1) instantiate the proxy and add to collection a_bs
    2.4) perform "select c.foreign_key from TABLE_A a, TABLE_C c where
c.foreign_key = a.primary_key"
    2.4) Iterate the result set. For each row:
        2.4.1) instantiate the proxy and add to collection a_cs

then, for each access to an object referenced through the collections a_bs
or a_cs, another SQL statement would be issued. Now say we have 2 instances
of A in the database, which both hold 20 references in each collection
attribute. I was to access all objects in the above described data set, over
time the number of SQL statement issued would be

1 + number_of_collection_attributes + (number_of_collection_attributes *
number_of_referenced objects),
i.e. 1 + 2 + 2 * 20 = 43.

This loading scheme is extremely inefficient, especially since the number of
statements issued increases linearily with the number of objects referenced
(and accessed) in the collections. A smart JDBC programmer (or O/R tool)
could handle all with 1 (!) outer join statement, or at most 3 statements.
If I am right, I dont think the proxy mechanism increases efficiency a lot,
since it only saves the object instantiation, but incurs a possibly
1000-fold increase of DBMS accesses.

I think a lazy relationship loading mechanism must be implemented such, that
it performs the foreign-key join query only when the relationship itself is
accessed ("resolved"). It should load the full object data (vs. only the
foreign keys). For proxy classes, it should keep the raw data in a cache
attached to the relationship, and instantiate from that cache. Everything
else (especially singular loading) is unacceptable in a production
environment.

Did I miss something?

Q3: ==================================
I am wondering about the field/class ids in the repository.xml file. Why
assign separate ids when the names would do just as well?

Q4: ==================================
Are there any plans to remove the need for separately mapping foreign key
attributes? I find this a rather annoying requirement, which clearly defeats
the notion of "transparence".


Of course I am willing to lend a hand in any of these matters
regards,
Christian

[OJB-developers] weekly status update

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

Hi all,

Please see the attached todo-list to see what's going on.
I've prepared a prerelease of the upcoming 0.7 release:
http://prdownloads.sourceforge.net/objectbridge/ojb-0.7.207-src.tgz

The API is complete but still a lot of things won't work in
client/server mode.
Once everything is working I will call it OJB 0.7.
The new features are mainly related to SQL based queries and accessing
the metadata layer via the PersistenceBroker.
When this is finished the persistence kernel API is complete! (Things
like M:N mapping, adding support for Joins, etc. can be done without
touching the API)
I'm planning to invite developers from the SourceForge community to
collaborate on a JDO implementation based on the OJB 0.7 API.

I'm on a short trip, so please don't expect quick replies in the next
few days...

--Thomas

AW: [Fwd: RE: [OJB-developers] Oracle sequences]

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

Hi again,


> Or do you use a code beautifier to have a defined standard? 
> Im using the
> JRefactory tool within JBuilder.
> 


I'm using the configurable code formatter that comes with the IDEA IDE.
It's really great and can do even things like cleaning up import
statements...

--Thomas

[OJB-developers] Cache implementations

[Bischof, R. <rai...@ed...>]

All,

just to ensure that we don't do work twice:

As time allows I will implement two special caches:
One that does not expire at all and keeps the object in cache for all times.
This is useful if you have only few objects that you want to keep in memory
because they are pretty expensive to re-build from DB.

The other will be a "Meta-Cache", i.e. a cache that uses other caches for
each class. That way we can use the not expiring cache for certain classes
and the default cache for others. That is you can set the
CacheImplementation for each class you want to be cached in a special way.

Regards
Rainer

RE: [Fwd: RE: [OJB-developers] Oracle sequences]

[Bischof, R. <rai...@ed...>]

With coding conventions I mean simple things like brackets, spaces ,etc
if(b==1){
  doIt();
}

is somewhat different from 

if ( b == 1 )
{
  doIt();
}

I personally prefer 
if( b==1 ){
  doIt();
} 

Mixing this up within the code base of one single project is no good idea, I
think.
Since you have done 99.99% of the project you should adhere to your personal
style and just define this as the standard for the project.
Or do you use a code beautifier to have a defined standard? Im using the
JRefactory tool within JBuilder.

Regards
rb


-----Original Message-----
From: Mahler Thomas [mailto:tho...@it...]
Sent: Freitag, 26. Oktober 2001 13:14
To: Bischof, Rainer; Obj...@li...
Cc: Mahler Thomas
Subject: AW: [Fwd: RE: [OJB-developers] Oracle sequences]


Hi Rainer,

thanks a lot for this contribution. I will integrate it into the next
release!
I've been a bit sloppy with the SequenceManagerDefaultImpl and did not care
to mark reusable methods as protected. I will fix this.
Regarding coding conventions I've no fixed ideas. Maybe we should improve on
this too...

--Thomas

AW: [Fwd: RE: [OJB-developers] Oracle sequences]

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

Hi Rainer,

thanks a lot for this contribution. I will integrate it into the next
release!
I've been a bit sloppy with the SequenceManagerDefaultImpl and did not care
to mark reusable methods as protected. I will fix this.
Regarding coding conventions I've no fixed ideas. Maybe we should improve on
this too...

--Thomas

FW: [Fwd: RE: [OJB-developers] Oracle sequences]

[Bischof, R. <rai...@ed...>]

oops, I forgot the modified SequenceManagerDefaultImpl

rb



-----Original Message-----
From: Bischof, Rainer 
Sent: Freitag, 26. Oktober 2001 09:56
To: 'Obj...@li...'
Cc: 'tho...@it...'
Subject: FW: [Fwd: RE: [OJB-developers] Oracle sequences]


All, 

please find attached an implementation of the High/Low SequenceMgr including
DDL and repository mapping definition.
In order not to re-invent the wheel I decided to extend the default
SequenceMgr. Therefore I had to change some access modifiers in the default
implementation from private to protected. The modified default
implementation is also attached.

Thomas, 
pls have a look and feel free to change whatever is not appropriate for OJB
(the coding conventions for example).

Cheers
Rainer


-----Original Message-----
From: Mahler Thomas [mailto:tho...@it...]
Sent: Mittwoch, 24. Oktober 2001 09:28
To: 'Thomas Mahler'
Cc: Objectbridge (E-Mail)
Subject: AW: [Fwd: RE: [OJB-developers] Oracle sequences]


Hi Ilia,

> 
> The SequenceManagerDefaultImpl.java implements MAX key 
> generator. Do you
> have plans to add HIGH/LOW key generator?
> 
> Thanks,
> 

The OJB SequenceManager is really rather simple (not to say primitive).
The OJB SequenceManager is pluggable. That is, it can easily replaced by
user defined version that implement different semantics (say HIGH/LOW key,
etc.).
See http://objectbridge.sourceforge.net/system/sequencemanager.html on this
subject.
I personally do not intent to implement an improved sequencemanager.
I just can't do ALL the work and want to encourage user contributions to the
OJB codebase.

Thus I'm cc'ing this mail to the OJB developer list. Maybe someone
volunteers for this...

HTH,

Thomas


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

FW: [Fwd: RE: [OJB-developers] Oracle sequences]

[Bischof, R. <rai...@ed...>]

All, 

please find attached an implementation of the High/Low SequenceMgr including
DDL and repository mapping definition.
In order not to re-invent the wheel I decided to extend the default
SequenceMgr. Therefore I had to change some access modifiers in the default
implementation from private to protected. The modified default
implementation is also attached.

Thomas, 
pls have a look and feel free to change whatever is not appropriate for OJB
(the coding conventions for example).

Cheers
Rainer


-----Original Message-----
From: Mahler Thomas [mailto:tho...@it...]
Sent: Mittwoch, 24. Oktober 2001 09:28
To: 'Thomas Mahler'
Cc: Objectbridge (E-Mail)
Subject: AW: [Fwd: RE: [OJB-developers] Oracle sequences]


Hi Ilia,

> 
> The SequenceManagerDefaultImpl.java implements MAX key 
> generator. Do you
> have plans to add HIGH/LOW key generator?
> 
> Thanks,
> 

The OJB SequenceManager is really rather simple (not to say primitive).
The OJB SequenceManager is pluggable. That is, it can easily replaced by
user defined version that implement different semantics (say HIGH/LOW key,
etc.).
See http://objectbridge.sourceforge.net/system/sequencemanager.html on this
subject.
I personally do not intent to implement an improved sequencemanager.
I just can't do ALL the work and want to encourage user contributions to the
OJB codebase.

Thus I'm cc'ing this mail to the OJB developer list. Maybe someone
volunteers for this...

HTH,

Thomas


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

AW: [Fwd: RE: [OJB-developers] Oracle sequences]

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

Hi Ilia,

> 
> The SequenceManagerDefaultImpl.java implements MAX key 
> generator. Do you
> have plans to add HIGH/LOW key generator?
> 
> Thanks,
> 

The OJB SequenceManager is really rather simple (not to say primitive).
The OJB SequenceManager is pluggable. That is, it can easily replaced by
user defined version that implement different semantics (say HIGH/LOW key,
etc.).
See http://objectbridge.sourceforge.net/system/sequencemanager.html on this
subject.
I personally do not intent to implement an improved sequencemanager.
I just can't do ALL the work and want to encourage user contributions to the
OJB codebase.

Thus I'm cc'ing this mail to the OJB developer list. Maybe someone
volunteers for this...

HTH,

Thomas

[OJB-developers] Oracle sequences

[Ilia I. <iio...@yd...>]

Hi
I have the following questions.
Can OJB generate new primary key for insert using oracle sequences? Is it
possible to specify sequence name for particular table / object?
Does RETURNING mode for oracle 8i is supported?
"INSERT INTO tableName (pkName,...) VALUES (sequenceName.nextval,...)
RETURNING primKeyName INTO ?" as Castor does.
If not what is the "OJB" way to add this feature?

Thanks

Ilia

[OJB-developers] New To OJB-Basic Question

[David A. <da...@al...>]

*This message was transferred with a trial version of CommuniGate(tm) Pro*
Team,

I have run the tutorials using the InstantDB and I am now ready to point 
the tutorials at MySQL. I have modified the repository.xml to indicate 
the change in DB, but of course I have yet to define the appropriate 
tables in the MySQL test db.

My questions:
	Does OJB ever automatically create the appropriate schema when an 
object is first persisted?
	Where is the appropriate DDL to generate a MySQL DB for the tutorials?


Thanks,

David Allen

[OJB-developers] weekly status update and new release !

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

Hi all,

Here is the weekly status update. See attached todo list.

There is also a new release focussing on documentation, bug fixes and a
Testsuite for the LockManager.

from the release notes:

Release 0.5.200

changes in this release:

New features
- Write Tutorial 3 
- Make access to OJB.properties configurable ( System property pref.) 
- Make implicit locking of associated objects configurable 
- Use the JDK 1.3 Dynamic Proxies for PB Lazy loading 
- Documentation for LockManager 

refactorings
- ODMG: no registering in Constructors of ODMG Collections 
- Unify Manual and Dynamic Proxy Mechanism, 
- provide compatibility patch for JDK 1.2 
- Remove superfluous methods from PB interface 
- Remove all code references to SequenceManager 
- Write a complete Testsuite for Locking mechanism 
- Integrate with new version 3.7 of JUnit framework 

bug fixes
- A bind / lookup sequence does not work within one transaction 
- ODMG: bind must register new objects to current transaction 
- ObjectStateTable.commit() must call PB.abort() in case of an exception 
- JDBCAcccess must use getBytes() to read BINARY, VARBINARY and
LONGVARBINARY 
- Make Identities extent aware 

best regards,

Thomas

[OJB-developers] weekly status update

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

Hi all,

attached you'll find the weekly update.

Colin Sampaleanu provided me with a cool link:

http://staff.develop.com/halloway/code/jcfe.html

this project developed a JDK1.2 based implementation of the JDK1.3
Dynamic Proxy classes.
By using this library it is possible to compile OJB under JDK1.2 without
any sourcecode modification!

Thanks again Colin for this smart solution.

Currently I'm working mostly on minor bug fixes and the third tutorial.
I hope to finish it during the next week. Once it is finished it's time
for a new release!

--Thomas

[OJB-developers] Re: OJB compatibility list

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

Hi Vishwanath,

thanks for your interest!

Vishwanath wrote:
> 
> Does it run with FileMaker database
> 

I personally have no experiences with OJB and FileMaker. I also have no
idea if anyone already works with this setup.

Thus I'm forwarding your mail to the OJB developer list, maybe someone
is already using it.

Is there a JDBC driver for FileMaker? If so there should be no serious
problems.

HTH,

Thomas

AW: [OJB-developers] Extent aware cache

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

Hi Michal,

please try to replace the constructor of ojb.broker.Identity with the
following code:

    public Identity(Object objectToIdentitify)
    {
        try
        {
	DescriptorRepository repository =3D
DescriptorRepository.getInstance();
            ClassDescriptor mif =3D
repository.getDescriptorFor(objectToIdentitify.getClass());
            // identities are unique across extents, thus use extent =
class
for identification:
            this.objectsClass =3D
repository.getExtentClass(objectToIdentitify.getClass());
            this.pkValues =3D mif.getKeyValues(objectToIdentitify);
        }
        catch (ojb.broker.metadata.ClassNotPersistenceCapableException =
ex)
        {
            throw new
org.odmg.ClassNotPersistenceCapableException(ex.getMessage());
        }
    }

To make this work for your example you must declare an Extent for =
Interface
A, containing class AImpl in the OJB XML Repository.
An example for declaring an Interface based Extent can be found in the
sample repository.xml.

please let me know if this fixes your problem.

HTH, Thomas


> -----Urspr=FCngliche Nachricht-----
> Von: Michal Kleczek [mailto:mkl...@ya...]
> Gesendet: Dienstag, 9. Oktober 2001 09:17
> An: obj...@li...
> Betreff: [OJB-developers] Extent aware cache
>=20
>=20
> Hi,
> I just found a serious bug in my application
> and it looks like the problem lays in ObjectCacheDefaultImpl.
> Situation looks like this:
>=20
> interface A {
> ...
> }
>=20
> class AImpl implements A {
> ...
> }
>=20
> class B {
>   A aReference;
> }
>=20
> class C {
>   AImpl aImplReference; //points to the same instance as B.aReference
> }
>=20
> After reading objects B and C should be:
> B.aReference =3D=3D C.aImplReference.
>=20
> But it is not!!!
> The problem is that cache is not aware of extents so:
> cache(B.aReference) puts <"A{x}", B.aReference> into the hashtable =
and
> lookup(C.aImplReference) looks for "AImpl{x}" and returns null.
>=20
> Regards,
> Michal
>=20
>=20
> _________________________________________________________
> Do You Yahoo!?
> Get your free @yahoo.com address at http://mail.yahoo.com
>=20
>=20
> _______________________________________________
> Objectbridge-developers mailing list
> Obj...@li...
> https://lists.sourceforge.net/lists/listinfo/objectbridge-developers
>=20

AW: [OJB-developers] Extent aware cache

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

Hi Michal,

The cache uses Identity objects as keys. thus the problem is related to
Identies and not so much to the cache.
Identities are composed from and objects Class and the Primary key values.
Currently obtaining an objects Identity does NOT return an extent aware
identity.
I don't know if it is possible to change this behaviour without any
problems. I'll check it and will try to provide a fix.

Thanks,

Thomas

> 
> After reading objects B and C should be:
> B.aReference == C.aImplReference.
> 
> But it is not!!!
> The problem is that cache is not aware of extents so:
> cache(B.aReference) puts <"A{x}", B.aReference> into the hashtable and
> lookup(C.aImplReference) looks for "AImpl{x}" and returns null.
> 
> Regards,
> Michal
> 
> 
> _________________________________________________________
> Do You Yahoo!?
> Get your free @yahoo.com address at http://mail.yahoo.com
> 
> 
> _______________________________________________
> Objectbridge-developers mailing list
> Obj...@li...
> https://lists.sourceforge.net/lists/listinfo/objectbridge-developers
> 

AW: [OJB-developers] weekly status update

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

Thanks for the cool link.
I'll try to use it for a JDK 1.2 based solution.

Thomas

> could use this code for 1.2; it should be almost no extra work:
> http://staff.develop.com/halloway/code/jcfe.html
> The license does not appear to be an issue...
> 
> Regards,
> 
> 
> _______________________________________________
> Objectbridge-developers mailing list
> Obj...@li...
> https://lists.sourceforge.net/lists/listinfo/objectbridge-developers
> 

RE: [OJB-developers] weekly status update

[<ll...@li...>]

Hi Thomas,

Sadly IBM doesn't support JDK 1.3 yet in its otherwise excellent
development environment VisualAge for Java.
Most IBM deployment environment also seems to suggest using JDK 1.2.

I didn't get a chance to try VAJ 4 yet. If that supports JDK 1.3 then I
think you can drop the JDK 1.2 support without further notice.
Otherwise there will be lots of JDK 1.2 users out there for a couple of
more years.

I saw that the JDOM project used ANT to replace the 1.2 collection
classes with the plug-in that came with 1.1. That might be possible in
this project also. I don't know if they dropped 1.1 support too by now,
but they were so kind as to support it at least until ibm came with VAJ
3.5

/Lazlo

(sorry if this is a repost)

-----Original Message-----
From: obj...@li...
[mailto:obj...@li...] On Behalf
Of Thomas Mahler
Sent: 1. januar 1997 00:20
To: objectbridge
Subject: [OJB-developers] weekly status update


Hi all,

here is the second edition of the weekly OJB status update.
See the attached html file to see the status of your bug and feature
requests.

In the last week I used the JDK 1.3 dynamic Proxy concept to build an
improvement of the OJB virtual proxy concept. Now you don't have to
implement the proxy classes yourself, but can declare the usage of
dynamic proxies in the the XML repository.

This works great and avoids a lot of non-productive work from for
app-developers using OJB.

There is only one problem: this feature requires JDK 1.3 or later.

I see 2 option to deal with this situation:
1. just say OJB needs JDK 1.3 or later. Period.
2. try to support a JDK 1.2 compliant version without this feature.

Of course 1.) will save me a lot of work. But maybe some of you still
rely on JDK 1.2 in certain production environments ? Please tell me if
you need OJB running under JDK 1.2.

The easiest way to provide a JDK 1.2 compliant version would be to use
compiler switches in the code. Unfortunately Java does not have a
preprocessor.
What is the best solution in Java to provide this kind of preprocessing?
Can we use ANT for this  work? Any hints are most welcome.

regards,

--Thomas

[OJB-developers] Extent aware cache

[Michal K. <mkl...@ya...>]

Hi,
I just found a serious bug in my application
and it looks like the problem lays in ObjectCacheDefaultImpl.
Situation looks like this:

interface A {
...
}

class AImpl implements A {
...
}

class B {
  A aReference;
}

class C {
  AImpl aImplReference; //points to the same instance as B.aReference
}

After reading objects B and C should be:
B.aReference == C.aImplReference.

But it is not!!!
The problem is that cache is not aware of extents so:
cache(B.aReference) puts <"A{x}", B.aReference> into the hashtable and
lookup(C.aImplReference) looks for "AImpl{x}" and returns null.

Regards,
Michal


_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

RE: [OJB-developers] weekly status update

[Colin S. <col...@ex...>]

> -----Original Message-----
> From: obj...@li...
> [mailto:obj...@li...]On Behalf Of
> Thomas Mahler
> Sent: Tuesday, December 31, 1996 6:20 PM
> To: objectbridge
> Subject: [OJB-developers] weekly status update
> ...
> In the last week I used the JDK 1.3 dynamic Proxy concept to build an
> improvement of the OJB virtual proxy concept. Now you don't have to
> implement the proxy classes yourself, but can declare the usage of
> dynamic proxies in the the XML repository.
>
> This works great and avoids a lot of non-productive work from for
> app-developers using OJB.
>
> There is only one problem: this feature requires JDK 1.3 or later.
>
> I see 2 option to deal with this situation:
> 1. just say OJB needs JDK 1.3 or later. Period.
> 2. try to support a JDK 1.2 compliant version without this feature.
>
> Of course 1.) will save me a lot of work. But maybe some of you still
> rely on JDK 1.2 in certain production environments ? Please tell me if
> you need OJB running under JDK 1.2.
>
> The easiest way to provide a JDK 1.2 compliant version would be to use
> compiler switches in the code. Unfortunately Java does not have a
> preprocessor.
> What is the best solution in Java to provide this kind of preprocessing?
> Can we use ANT for this  work? Any hints are most welcome.

Needing JDK/JRE 1.3 or higher is not that big a deal to me, but maybe you
could use this code for 1.2; it should be almost no extra work:
http://staff.develop.com/halloway/code/jcfe.html
The license does not appear to be an issue...

Regards,