objectbridge-developers — public list for developer issues

Re: [OJB-developers] AW: [Fwd: SODA support]

[Carl R. <ca...@db...>]

Hi Thomas, Jesper, OJB,


> I'm planning to have a full support for SODA. I really like Carl
> Rosenbergers initiative.

Thanks!

Thomas P=F6schmann also volunteers to contribute.

He just ordered a SourceForge project, so we can try
to coordinate the work on the API in the future.

I would really enjoy to share samples and test code.
I will send a message when the site is up.


> I implemented a rough version of SODA support to show Carl that it will
> quite straightforward to integrate this into OJB.

My compliments!


> I hoped that he could
> write the Contraint --> Query translator.
> He planned to start to work on his this in March, but I think he has no=
t
> done much in this direction.

Indeed I did not really get back to work on S.O.D.A. yet.
We have set the release date for our own implementation to
the end of June, so I will have to.


> As SODA is not in the core focus for OJB 1.0 there is currently not muc=
h
> pressure to finish things soon.
> As always: If someone volunteers it can be done very quickly. If no one
> volunteers I will start working on it after the 1.0 release (i.e. after
> June).

(S.O.D.A. stands for "Simple Object Database Access". I prefer to write i=
t
with the points, since Rational has a product named "Soda".)

The S.O.D.A.  API is more powerful than it looks.
The current syntax could be used to do some highly complex things.
I wouldn't underestimate the problems to port all the possibilities
to a relational database. I will put up some more samples on the
SourceForge site soon.


Kind regards,
Carl
---
Carl Rosenberger
db4o - database for objects - http://www.db4o.com

[OJB-developers] AW: [Fwd: SODA support]

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

Hi Jesper

> -------- Original Message --------
> Subject: SODA support
> Date: Mon, 15 Apr 2002 12:29:21 +0200
> From: jl...@pi... (Jesper Ladegaard)
> To: "Thomas Mahler" <tho...@ho...>
> 
> Hi Thomas,
> 
> The SODA stuff you've been integrating into OJB lately, what 
> is the status
> of this?

There is only one thing missing in this implementation to complete its
functionality:
It does not contain a translator from SODA Constraints to OJB queries right
now.

everything else is working.

> 
> What SODA api features do you support now, and what will be 
> supported in
> future versions?

I'm planning to have a full support for SODA. I really like Carl
Rosenbergers initiative.
For ODMG users it should be possible to use OQL, OJB Queries and SODA.
(currently OJB allows to use OQL, OJB Queries, and the (unfinished) SODA API
within ODMG applications).
For JDO users it should be possible to use JDOQL, OJB Queries and Soda.

> The reason for asking is that we're probably going to base 
> some query stuff
> on SODA. So, I'm very interested in knowing if, how, who, why 
> and when the
> SODA support is going to be implemented.

I implemented a rough version of SODA support to show Carl that it will
quite straightforward to integrate this into OJB. I hoped that he could
write the Contraint --> Query translator.
He planned to start to work on his this in March, but I think he has not
done much in this direction.

As SODA is not in the core focus for OJB 1.0 there is currently not much
pressure to finish things soon.
As always: If someone volunteers it can be done very quickly. If no one
volunteers I will start working on it after the 1.0 release (i.e. after
June).

cu,

Thomas

> Thanks!
> Jesper
> 
> 
> 
> 
> 

RE: [OJB-developers] More JCA

[Matthew B. <ma...@so...>]

Summary: I will be cleaning up the code tonight for another round, this will
include proper connection and transaction contract fulfillment including
only LocalTransaction Support. I'll need assistance on the XA
implementation.

No, the issue is related to JCA.

Please read the JCA spec section 5.5.4. Especially the part "Connection 
Sharing and Multiple Connection Handles". Then, for example, try look at the

JCA-compliant JDBC wrapper provided with JBoss as an example how to get 
around the problem.

Another approach is to do it after the book. That is, support resource 
sharing for real. However, this implies supporting and testing all kinds of 
scenarios such as interleaving of multiple transactions on the same 
connection, joining of transaction, thread-safety and more. Also, many of
the 
issues are related to XA. For example local transactions have no concept of 
XID, so it's pretty much impossible to do transaction interleaving here. 
Resource sharing from a XA point of view is described in the JTA spec
section 
3.4.6.


> Ok, I have the spec and a JCA book I'm using. I'll nail this one.

Well, using logical JNDI names is the standard way to access external 
resources in EJB 2.0. There's also several good reasons why to actual do it.

Here's a description how to declare resource references in Jboss: 
http://www.jboss.org/online-manual/HTML/ch07s02.html

Also, not doing this and you might get grilled by unpleasant EJB individuals

when the stuff reaches out to the hardcore J2EE community. I actually once 
got death threats from a J2EE developers when I said that EJB was the
perfect 
anti-pattern. Well, I guess one can't compare this with not using resource 
references in ejb-jar.xml :-) However, just take it as a hint then.

> ok this is just the indirection from using the name I bound the resource
too. No problem will add to my example. I don't want any death-threats :)

What JCA's did you look at?

Commercial JDO product, just looked at the sample ejb.

In a managed environment the connection manager of the application server 
controls the pool. OJB should only create connections when told to do so by 
the server.

> Agree, but wondered about all the calls to new database vs current
database.

Okay. But, if you could look at the connection related stuff and make sure
it 
is compliant with the spec, that would be nice. Because, it's your code and 
you know best how the connection handling part of it is supposed to work.

> yep, will do.

Well, there are several issues around XA, but of course it can be done. 
However, I'll need to try get some connector stuff running in this Trifork 
application server first. Thereafter I'll go for the XA stuff, probably in 
the very near future, say in a couple of weeks.

> hopefully the jca piece is portable. Why did you guys choose Trifork? What
are the advantages of that application server?

However, if you can get a robust JCA version up running with local 
transactions that would be a major step also! XA it only needed in the more 
advanced transaction scenarios where several resource adapters are involved.

I guess most "normal" people don't need these features right away, but I 
could be wrong of course.

> Yah, XA is advanced, and we will need it in about 6 months. I really want
to learn all about it as well, but time is not on my side.

What about the non-CCI ODMG factory interface and the BMT stuff we talked 
about, do you intent to look at this also, or what is your plan?

> I'm going to implement the non-CCI ODMG factory as well as the PBroker
factory, and the BMT stuff.

regards,
Matthew

[OJB-developers] More JCA

[Jesper L. <je...@da...>]

Hi again Matthew,

What is the status on your JCA adapter?

Below is my reply to the last mail.

> 4) In the non-managed client, you call commit directly on odmg.Transaction?
> 
> > In the non managed client, don't I have to handle any transaction myself?
> Maybe I misunderstood, but I assumed this would be like using the managed
> connection in a BMT environment.

You're right. I was sleeping!

[Multiple connection & resource sharing]

> Are you sure your connection handling (i.e. 
> OJBMannagedConnection.getConnection) is correctly implemented? I wonder why 
> there's no set or anything holding the currently allocated connection 
> handles. Are you sure this will work correctly if a bean developer obtains 
> multiple connection handles (through OJBConnectionFactory), or if the 
> application server uses resource sharing among bean?
> 
> > This is a really good point, and I admit to not thoroughly looking at how
>  OJB worked, but I assumed that since I was returning the proxy object (A
>  wrapper to the Implementation) and that the implementation used a singleton
>  OJB.... I'm unclear on this.

No, the issue is related to JCA.

Please read the JCA spec section 5.5.4. Especially the part "Connection 
Sharing and Multiple Connection Handles". Then, for example, try look at the 
JCA-compliant JDBC wrapper provided with JBoss as an example how to get 
around the problem.

Another approach is to do it after the book. That is, support resource 
sharing for real. However, this implies supporting and testing all kinds of 
scenarios such as interleaving of multiple transactions on the same 
connection, joining of transaction, thread-safety and more. Also, many of the 
issues are related to XA. For example local transactions have no concept of 
XID, so it's pretty much impossible to do transaction interleaving here. 
Resource sharing from a XA point of view is described in the JTA spec section 
3.4.6.


[resource factory lookup]

>The first question is why the example does not use JNDI ENC and define a 
> resource-ref in ejb-jar.xml? I will argue that all EJB examples provided
> with 
> the JCA adapter must do this.
 
> > obviously this isn't required for it to work, but I'm missing the finer
> points of why to do this. Can you explain. 

Well, using logical JNDI names is the standard way to access external 
resources in EJB 2.0. There's also several good reasons why to actual do it.

Here's a description how to declare resource references in Jboss: 
http://www.jboss.org/online-manual/HTML/ch07s02.html

Also, not doing this and you might get grilled by unpleasant EJB individuals 
when the stuff reaches out to the hardcore J2EE community. I actually once 
got death threats from a J2EE developers when I said that EJB was the perfect 
anti-pattern. Well, I guess one can't compare this with not using resource 
references in ejb-jar.xml :-) However, just take it as a hint then.


> I've looked at other JCA's that
> don't have a resource-ref element in the ejb-jar.xml.

What JCA's did you look at?

>
> Moreover, I do not understand why to think of org.odmg.Implementation as a 
> connection? That is, I think it would be more intuitive if Implementation
> was 
> the resource factory interface and not the connection handle. Also, what if 
> the user creates multiple database connection calling newDatabase, how
> should 
> pooling work then?
 
> > I thought the point was to allow people to connect to multiple databases
> via "newDatabase", and that OJB was handling the pooling itself.

In a managed environment the connection manager of the application server 
controls the pool. OJB should only create connections when told to do so by 
the server.

[snip...]

> > I'm a bit too swamped at work to do the XA work, although I'd love to be
> involved.

Okay. But, if you could look at the connection related stuff and make sure it 
is compliant with the spec, that would be nice. Because, it's your code and 
you know best how the connection handling part of it is supposed to work.

> What is your ability to do some of this work? As you know, the
> code is pretty small, mostly writing wrappers and stuff.

Well, there are several issues around XA, but of course it can be done. 
However, I'll need to try get some connector stuff running in this Trifork 
application server first. Thereafter I'll go for the XA stuff, probably in 
the very near future, say in a couple of weeks.

However, if you can get a robust JCA version up running with local 
transactions that would be a major step also! XA it only needed in the more 
advanced transaction scenarios where several resource adapters are involved. 
I guess most "normal" people don't need these features right away, but I 
could be wrong of course.

> 
> Again, thanks for the excellent feedback. I'm going to do the easier stuff
> on this list then package it up and send it to you, Jesper, if you have some
> time to implement more of your ideas.

What about the non-CCI ODMG factory interface and the BMT stuff we talked 
about, do you intent to look at this also, or what is your plan?

Regards
Jesper

[OJB-developers] Re: WG: PlatformOracleImpl

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

Hi Chris,

Thanks for your contribution. I commited it to CVS.
I also slightly changed the interaction of Platform and StatementsForClas=
s.
This allows PlatformImplementations to have better control of jdbc=20
connection settings.

Mahler Thomas wrote:

>=20
>>-----Urspr=FCngliche Nachricht-----
>>Von: Chris Greenlee [mailto:CGr...@de...]
>>Gesendet: Donnerstag, 11. April 2002 18:00
>>An: Mahler Thomas
>>Betreff: PlatformOracleImpl
>>
>>
>>Thomas,
>>
>>Attached is a PlatformOracleImpl that includes some modifications for
>>working with binary data (serializing objects and such) in Oracle.  It
>>also requires that StatementsForClass become a public class in the
>>accesslayer package, since the Oracle Thin driver requires that Escape
>>Processing be enabled in many cases.
>>
>>If you could commit this, we would greatly appreciate it. :)
>>
>>And thanks for getting the CVS repository back up to date!
>>
>>Cheers,
>>
>>Chris
>>
>=20
>=20

Re: [OJB-developers] Single VM Object Cache Consistency?

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

Hi John,

<snip>

 >
 >
 > I'm working on trying to change things so that
 >
 > a) Each PB has its own private object cache which is transactionally
 > consistent (the cache is flushed on each commit/abort tx.  This behavior
 > is controlled via OJB.properties.


great news !


 >
 > b) Classes can be marked for "VM wide" caching (multiple PBs will share
 > these objects).  These classes must be thread safe and used to hold
 > "read only" data from the database.  This cache is not flushed
 > automatically when tx's commit/abort.
 >


good idea!


 > I've got it coded and I'm testing it out more today.  It is mostly a new
 > cache implementation class - the impact on the rest of the code is
 > actually pretty minimal (and this new behavior can be turned on/off
 > easily).
 >


that's good!


 > However, your comment about the cache providing "uniqueness of
 > persistent Objects across a VM" concerns me.  Clearly with PB local
 > caches, you can have multiple object instances in the VM that have
 > identical database identity.  From what I can tell, I don't see this as
 > a problem, but with your greater experience do you see any problems with
 > the above approach?


I agree with you: if the transaction local caches are flushed on tx
commit I see no problems with this approach.

 > Would this play havoc with the higher layers that
 > I'm not familiar with (odmg or the planned jdo)?
 >


No, should be harmless.

thanks for your efforts!

Thomas


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

RE: [OJB-developers] Single VM Object Cache Consistency?

[John F. <jfr...@so...>]

Hi Thomas,

> The original intention of a cache was not primarily to boost=20
> performance but to maintain uniqueness of persistent Objects accross a
VM.
> But without tx isolation on the PB level this is dangerous as your
> example shows. Maybe we need a redesign of this aspect. There are
similar thoughts in
> the JDO spec. They only provide uniqueness of objects within one
> transaction.
>=20
> having transaction local caches would be the most simple solution and
> simplify a lot of things (e.g. cache synchronization).


I'm working on trying to change things so that

a) Each PB has its own private object cache which is transactionally
consistent (the cache is flushed on each commit/abort tx.  This behavior
is controlled via OJB.properties.

b) Classes can be marked for "VM wide" caching (multiple PBs will share
these objects).  These classes must be thread safe and used to hold
"read only" data from the database.  This cache is not flushed
automatically when tx's commit/abort.

I've got it coded and I'm testing it out more today.  It is mostly a new
cache implementation class - the impact on the rest of the code is
actually pretty minimal (and this new behavior can be turned on/off
easily).

However, your comment about the cache providing "uniqueness of
persistent Objects across a VM" concerns me.  Clearly with PB local
caches, you can have multiple object instances in the VM that have
identical database identity.  From what I can tell, I don't see this as
a problem, but with your greater experience do you see any problems with
the above approach?  Would this play havoc with the higher layers that
I'm not familiar with (odmg or the planned jdo)?

Regards,
 - John

AW: [OJB-developers] Single VM Object Cache Consistency?

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

Hi John,

 
> I've worked through just about every technical question I 
> have on OJB's
> applicability to my current project.  The last nagging question I have
> is about object cache consistency.
> 
> I see that within a single VM that multiple PersistenceBrokers share a
> singleton object cache.

right.
 
<snip treading example>
> 
> In this scenario, the db transactions within each thread become
> intertwined in a way because each thread has no idea the other thread
> may have made additional changes to the object state within 
> the context
> of its own transaction.  It could easily end up committing unintended
> state changes.
> 

You are right. There is no protection of this kind on the PersistenceBroker 
level as it provides no Object level transaction management.
This is currently only possible if you were using the OJB-ODMG API that
provides
a full fledged Object level Transaction management.

http://objectbridge.sourceforge.net/system/lockmanager.html


> Also, this would seem to indicate that every class that could be
> persisted with OJB would need to be either immutable or 
> thread safe (if
> you are using OJB in this sort of context).
> 
> Is there some other common way folks get around this that I'm 
> completely
> missing (or something else OJB is doing behind the scenes)?

On the PB level there is not much going on behind the scenes...

> It really seems like in this sort of context that each PB should have
> its own object cache which is flushed after each transaction
> commit/rollback.  

The original intention of a cache was not primarily to boost performance 
but to maintain uniqueness of persistent Objects accross a VM.

But without tx isolation on the PB level this is dangerous as your
example shows.
Maybe we need a redesign of this aspect. There are similar thoughts in
the JDO spec. They only provide uniqueness of objects within one
transaction.

having transaction local caches would be the most simple solution and
simplify a lot of things (e.g. cache synchronization).

> Or create a more sophisticated object cache that you
> could mark some classes as immutable so that they could be 
> shared across
> transactions & threads this way.  Actually, it looks like the
> MetaObjectCacheImpl may be just what I'm looking for.
> 

No, the MOC is just a hierarchical cache that allow to use one 
dedicated cache per class.
There is currently nothing of your ideas implemented there.

cu,

Thomas

> Thoughts?
> 
> Thanks much,
>  - John Freeborg
> 
> _______________________________________________
> Objectbridge-developers mailing list
> Obj...@li...
> https://lists.sourceforge.net/lists/listinfo/objectbridge-developers
> 

RE: [OJB-developers] build.xml

[Chris G. <CGr...@de...>]

As a warning, if you use this your source files will show up as
modified, since the files in CVS are in DOS format.

C.

> -----Original Message-----
> From: Chris Greenlee=20
> Sent: Thursday, April 11, 2002 4:12 PM
> To: obj...@li...
> Subject: [OJB-developers] build.xml
>=20
>=20
>=20
> Apologies for the previous empty email -- I thank Outlook. =3D)
>=20
> Could you apply the following patch to the build.xml file?  This will
> fix the problem with the CodeSwitcher converting all files to=20
> DOS format
> every time it runs.
>=20
> Cheers,
>=20
> Chris Greenlee
>=20
> Index: build.xml
> =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> RCS file: /cvsroot/objectbridge/ojb-1-0/build.xml,v
> retrieving revision 1.12
> diff -u -r1.12 build.xml
> --- build.xml   8 Apr 2002 16:59:26 -0000       1.12
> +++ build.xml   11 Apr 2002 21:08:41 -0000
> @@ -48,6 +48,7 @@
>              <arg value=3D"${JDK}" />
>              <arg value=3D"${DEBUG}" />
>                 </java>
> +        <fixcrlf srcdir=3D"${source}" includes=3D"**/*.java"
> excludes=3D"**/CVS/**/*" />
>         </target>
>=20
>      <!-- Delete all the directories created in prepare -->
>=20
> _______________________________________________
> Objectbridge-developers mailing list
> Obj...@li...
> https://lists.sourceforge.net/lists/listinfo/objectbridge-developers
>=20

[OJB-developers] build.xml

[Chris G. <CGr...@de...>]

Apologies for the previous empty email -- I thank Outlook. =3D)

Could you apply the following patch to the build.xml file?  This will
fix the problem with the CodeSwitcher converting all files to DOS format
every time it runs.

Cheers,

Chris Greenlee

Index: build.xml
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
RCS file: /cvsroot/objectbridge/ojb-1-0/build.xml,v
retrieving revision 1.12
diff -u -r1.12 build.xml
--- build.xml   8 Apr 2002 16:59:26 -0000       1.12
+++ build.xml   11 Apr 2002 21:08:41 -0000
@@ -48,6 +48,7 @@
             <arg value=3D"${JDK}" />
             <arg value=3D"${DEBUG}" />
                </java>
+        <fixcrlf srcdir=3D"${source}" includes=3D"**/*.java"
excludes=3D"**/CVS/**/*" />
        </target>

     <!-- Delete all the directories created in prepare -->

[OJB-developers] (no subject)

[Chris G. <CGr...@de...>]

[OJB-developers] Single VM Object Cache Consistency?

[John F. <jfr...@so...>]

I've worked through just about every technical question I have on OJB's
applicability to my current project.  The last nagging question I have
is about object cache consistency.

I see that within a single VM that multiple PersistenceBrokers share a
singleton object cache.

Isn't this a problem for multi-threaded applications (like a servlet
container)?  For example:

  Thread A gets a PB from the pool
  Thread B gets a PB from the pool
  Thread A calls PB.beginTransaction()
  Thread B calls PB.beginTransaction()
  Thread A looks up the xyz BankAccount object - this ends up loading
the BankAccount object into the shared object cache
  Thread B looks up the xyz BankAccount object and is returned a
reference to the same object instance from the shared object cache
  Thread A & B concurrently access the single xyz BankAccount object,
possibly corrupting things, but each is certainly unaware that the other
thread even exists
  Thread A calls PB.store(xyz BankAccount object)
  Thread B calls PB.store(xyz BankAccount object)
  Thread A calls PB.commitTransaction()
  Thread B calls PB.commitTransaction()

In this scenario, the db transactions within each thread become
intertwined in a way because each thread has no idea the other thread
may have made additional changes to the object state within the context
of its own transaction.  It could easily end up committing unintended
state changes.

Also, this would seem to indicate that every class that could be
persisted with OJB would need to be either immutable or thread safe (if
you are using OJB in this sort of context).

Is there some other common way folks get around this that I'm completely
missing (or something else OJB is doing behind the scenes)?

It really seems like in this sort of context that each PB should have
its own object cache which is flushed after each transaction
commit/rollback.  Or create a more sophisticated object cache that you
could mark some classes as immutable so that they could be shared across
transactions & threads this way.  Actually, it looks like the
MetaObjectCacheImpl may be just what I'm looking for.

Thoughts?

Thanks much,
 - John Freeborg

Re: [OJB-developers] Double checked locking & OJB

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

Hi John,

John Freeborg wrote:

> Forgive me - I don't want to seem critical here - I'm pretty excited
> about using OJB and the potential it has!
> 
> However, I've read in a number of places that double checked locking
> (DCL) isn't really safe in Java:
> 
> http://www.javaworld.com/javaworld/jw-02-2001/jw-0209-double.html
> http://www.javaworld.com/javaworld/jw-05-2001/jw-0525-double.html
> http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html
> 
> I've noticed that a few spots in OJB sort of use DCL, but don't really
> do full DCL as there is no second check after the synchronized()
> statement (see comment):


I'm well aware of the Java DCL problems. Even if our code had the second 
check there is no real protection.

Of course we might use synchronized on the method level, but that would 
decrease performance for the "normal" flow, where the singleton instance 
is already present.

All the classes you mention don't have state that could be corrupted by 
having duplicate instances.

in places where object state could be corrupted we always use proper 
synchronization on method level.

If you find any places where this is not the case it is a bug and needs 
to be fixed!

cu,

Thomas


> 
>   public static LockManager getLockManager()
>   {
>         if (LOCKMAN == null)
>         {
>             synchronized (LockManager.class)
>             {
>                 // This would be DCL, but the code doesn't have this
> second check
>                 //  if (LOCKMAN == null)
>                 LOCKMAN = createNewLockManager();
>             }
>         }
>         return LOCKMAN;
>   }
> 
> LockMapFactory, SequenceManagerFactory, PersistentFieldFactory,
> ObjectCacheFactory seem to use this same style of singleton creation.
> 
> If folks believe otherwise on DCL, I'd like to know as I try to follow
> that sort of stuff.  Otherwise it is probably safer to simply make these
> methods synchronized.
> 
> I worry about this as I'm planning on using OJB inside a servlet
> container where there are a lot of PersistenceBroker objects that may be
> concurrently calling these methods (and running on a dual processor
> box).
> 
> Thanks, 
>   - John Freeborg
> 
> 
> _______________________________________________
> Objectbridge-developers mailing list
> Obj...@li...
> https://lists.sourceforge.net/lists/listinfo/objectbridge-developers
> 
> 
> 
> 

[OJB-developers] Double checked locking & OJB

[John F. <jfr...@so...>]

Forgive me - I don't want to seem critical here - I'm pretty excited
about using OJB and the potential it has!

However, I've read in a number of places that double checked locking
(DCL) isn't really safe in Java:

http://www.javaworld.com/javaworld/jw-02-2001/jw-0209-double.html
http://www.javaworld.com/javaworld/jw-05-2001/jw-0525-double.html
http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html

I've noticed that a few spots in OJB sort of use DCL, but don't really
do full DCL as there is no second check after the synchronized()
statement (see comment):

  public static LockManager getLockManager()
  {
        if (LOCKMAN =3D=3D null)
        {
            synchronized (LockManager.class)
            {
                // This would be DCL, but the code doesn't have this
second check
                //  if (LOCKMAN =3D=3D null)
                LOCKMAN =3D createNewLockManager();
            }
        }
        return LOCKMAN;
  }

LockMapFactory, SequenceManagerFactory, PersistentFieldFactory,
ObjectCacheFactory seem to use this same style of singleton creation.

If folks believe otherwise on DCL, I'd like to know as I try to follow
that sort of stuff.  Otherwise it is probably safer to simply make these
methods synchronized.

I worry about this as I'm planning on using OJB inside a servlet
container where there are a lot of PersistenceBroker objects that may be
concurrently calling these methods (and running on a dual processor
box).

Thanks,=20
  - John Freeborg

RE: [OJB-developers] JCA implementation comments and ideas

[Matthew B. <ma...@so...>]

First of all, Excellent feedback Jesper. This is some really good stuff


Comments:

1) The close() implementation is missing (method empty) in your adapter 
specific connection implementation. The close method must somehow delegated 
to the ManagedConnection implementation and notify all listeners with a 
CONNECTION_CLOSED event. The reason that it seem to work, is because the 
container and connection manager of the application server garbage collects 
unused connection that the user (bean developer) forgets to close.

> Yep. I started working on this pre 0.8.375, and I thought I remembered
reading something about the close method not being correct for a JTA
environment quite yet. So I simply ignored it :)
 
2) The ManagedConnection.destroy() implementation does nothing but setting 
_proxy to null?

> Yes. It *should* close the proxy, release all the other resources (the
local transaction, the meta data, the request info, everything else). 

3) In the client examples provided, there's no call to close() on the 
connection handles???

> My bad, I think I got too excited when it started to work :) Of course the
close should be called.

4) In the non-managed client, you call commit directly on odmg.Transaction?

> In the non managed client, don't I have to handle any transaction myself?
Maybe I misunderstood, but I assumed this would be like using the managed
connection in a BMT environment.

5) Are you sure your connection handling (i.e. 
OJBMannagedConnection.getConnection) is correctly implemented? I wonder why 
there's no set or anything holding the currently allocated connection 
handles. Are you sure this will work correctly if a bean developer obtains 
multiple connection handles (through OJBConnectionFactory), or if the 
application server uses resource sharing among bean?

A solution may be to implement some kind of session or connection handle 
object (holding a pointer to the actual connection) that is returned from
the 
ManagedConnection. This also makes it easier to track what the application 
server is doing in the more complex scenarios. Also, I'm not sure if we can 
avoid this if we allow for resource sharing. At least if you don't support 
resource sharing, you should throw a ResourceException if somebody calls 
getConnection on ManagedConnection multiple times. The problem with resource

sharing is that we can't really test this on JBoss because the it's current 
connection manager don't support resource sharing yet. So, its important to 
follow the spec here and throw exceptions the right places if we cannot 
handle resource sharing, otherwise we might get in trouble with other 
application servers.

> This is a really good point, and I admit to not thoroughly looking at how
OJB worked, but I assumed that since I was returning the proxy object (A
wrapper to the Implementation) and that the implementation used a singleton
OJB.... I'm unclear on this.

6) In your non-mananaged and managed client scenario, something that I don't

understand is why does the TestClient and ProductServiceBean work different 
with the resource manager factory (OJBConnectionFactory), i.e one invokes 
createOJBConnection(), the other uses getConnection()? The general idea is 
that the resource manager factory should work the same in non-managed and 
managed scenarios. Also, how is the fine OJBConnectionManager you've created

ever going to be used if you call createOJBConnection?

> the non managed test client isn't implemented correctly. I will fix this.
I changed the method signature from createOJBConnection to the cci method
getConnection. My bad, however it seems we'll probably change those calls to
get different types of connections anyway.


7) You've created the resource manager factory using the Common Client 
interface (CCI). I do not quite understand the philosophy behind this 
decision? Can you elaborate why you use CCI.

> At first I had some trouble getting JBoss to use my resource properly
(acquire transactions automatically) so I thought it might have somethign to
do with the CCI (I'm lazy I know, should have read the source). No reason to
use the CCI in this case, but really no reason not to, except that we'll be
returning multiple connection types, so let's get rid of the CCI stuff.

In the ProductService session bean you do something like this:

String pmname = "java:/OJB"
Object ob = new InitialContext().lookup(pmname);
OJBConnectionFactoryImpl fac = (OJBConnectionFactoryImpl) ob;
Implementation connection = (Implementation) fac.getConnection();
Database db = connection.newDatabase();
..open db, do stuff, and so on

The first question is why the example does not use JNDI ENC and define a 
resource-ref in ejb-jar.xml? I will argue that all EJB examples provided
with 
the JCA adapter must do this.

> obviously this isn't required for it to work, but I'm missing the finer
points of why to do this. Can you explain. I've looked at other JCA's that
don't have a resource-ref element in the ejb-jar.xml.

You cast to OJBConnectionFactoryImpl, why?

> bad coding. I wrote the JCA in about 4-5 hours. I needed to know that it
would work in the JBoss environment.

Moreover, I do not understand why to think of org.odmg.Implementation as a 
connection? That is, I think it would be more intuitive if Implementation
was 
the resource factory interface and not the connection handle. Also, what if 
the user creates multiple database connection calling newDatabase, how
should 
pooling work then?

> I thought the point was to allow people to connect to multiple databases
via "newDatabase", and that OJB was handling the pooling itself.

8) I don't understand your TransactionDelegate thing. Can you elaborate how 
this is supposed to work and how to use it.

> I'll explain in another email.

--------


Here's some ideas/suggestions:

1) resource manager factory interface

I would suggest to have a resource manager factory interface for each type
of 
persistence API. The factory interfaces will be 
ojb.broker.PersistenceBrokerFactory for OJB "native",
org.odmg.Implementation 
for ODMG, and javax.jdo.PersistenceManagerFactory for JDO.In ODMG mode, both

Implementation, Database and Transaction should be wrapped. The 
org.odmg.Database will map to ManagedConnection.


For example:

OJB:
ctx = new InitialContext();
PersistenceBrokerFactory fac = (PersistenceBrokerFactory) ctx.lookup
( "java:comp/env/ojb/mydb" );
PersistenceBroker broker = fac.createNewBrokerInstance();
/* do stuff */
broker.close();


ODMG:
ctx = new InitialContext();
Implementation odmg = (Implementation) ctx.lookup
( "java:comp/env/odmg/mydb" );
Database db = odmg.newDatabase();
db.open(databaseName, Database.OPEN_READ_WRITE);
Transaction tx = odmg.newTransaction();
/* do stuff */
db.close();


JDO:
ctx = new InitialContext();
PersistenceManagerFactory fac = (PeersistenceManagerFactory) ctx.lookup
( "java:comp/env/jdo/mydb" );
PersistenceManager pm = fac.getPersistenceManager(user, passwd);
/* do stuff */
pm.close();


I think issue on how the resource factory interfaces should work is
extremely 
important, and something we must agree on. In the JDO case, there's not so 
much to discuss, because the JDO spec dictates how it should work. However, 
in the other two cases we must discuss and agree on how it should work
before 
starting to use the JCA connector for real. Otherwise, it will be very 
difficult to change it later on, and things might get messy. That is, we'll 
get unhappy users, because they have to change their client code.

> Although an important point, it's also pretty easy to understand, thanks
for your examples, it makes it pretty clear that the way you've outlined the
factories working is coherent across API's, and probably the right thing to
do.


Another thing, I think it would be cool if the JCA-based factory interfaces 
was the default way to use OJB in non-managed environments in the future. It

would provide OJB a nice and standard low-level connection and transaction 
mechanism. The idea of having a connection manager with standard interfaces 
is an extremely nice one. This also makes it a lot easier to provide better 
QoS in the connection mechanism by using code (say borrowing ideas) from 
other cool JCA-aware connection manager implementations.

> yep.


If we used JCA and JTA/XA in the OJB OTM core also, we would more-or-less 
have the generic OTM mechanism Thomas talked about in the JDO proposal. It 
should then be designed to work with OJB, ODMG and JDO on top, and provide 
standard-based connection management (javax.resource.spi package) and 
transaction management (javax.transaction.xa package) in the transaction 
layer below. When running in managed-environments we'll "just" have to
switch 
over control to the connection manager in the application server and vice 
versa. This is of course not something needed right away, however I think 
it's good to have this in mind when XA is added to the adapter.

> agreed, not needed now, can be implemented in future.


2) Transaction handling

Have you thought about supporting bean-managed transactions as defined in
the 
JDO spec in ODMG mode also? 

The idea is, that the user can both use the persistence API(s) transaction 
interface (i.e. org.odmg.Transaction, javax.jdo.Transaction or 
ojb.PersistenceBroker) or UserTransaction directly to demarcate transaction 
in beans with bean-managed transaction. If the persistence specific 
transaction API is used, then the transaction implementation will delegate
to 
UserTransaction (see JDO-spec 16.1.3).

I think this is nice because it allows the same code to run in both managed 
and non-managed scenarios without much change. But more important, when 
calling commit/rollback on i.e. org.odmg.Transaction running within a 
container-managed transaction the container will detect this and throw an 
exception!

> haven't tested with BMT, but I thought that should "just work", ie the
user requests a transaction and the container pokes the resource to start
one. Same as in the CMT mode, but with the user initiating.

Not wrapping the ojb.odmg.TransactionImpl the container or JCA adapter will 
not be able to check this, and changes may be committed or rolled back to
the 
database even that it's illegal for the user to do this using CMT. This
might 
very well screw up things, for example if the container wants to rollback 
later after the user has called commit.

> yeek. True.

For example in a bean with CMT:

/* user updates stuff */
Transaction tx = odmg.currentTransaction();
tx.commit();
/* 
  now some other code call setRollbackOnly or an unchecked exception 
  is thrown, which means that the container will roll-back the 
  transaction. Not very good, because the stuff is already 
  committed to the database by OJB's transaction manager!!!
*/

------

Other things I would like to discuss also is Resource adapter configuration 
(i.e. when having multiply ManageConnectionFactory configurations/resources-
managers set-up), and how to get JTA/XA into the adapter. XA is a very 
important for me, because of the need to use OJB together with other
XA-aware 
resource managers and therefore need 2PC and DTM support. Also, I'm probably

going to use the stuff in another app-server called Trifork pretty soon. So,

we'll get the adapter compatibility tested and know if the stuff works on 
other application servers also. 

However, I'll suggest we try discuss and agree on the connection factory 
interfaces and user transaction demarcation first. IMO, this is most 
important right now.

> I'm a bit too swamped at work to do the XA work, although I'd love to be
involved. What is your ability to do some of this work? As you know, the
code is pretty small, mostly writing wrappers and stuff.

Again, thanks for the excellent feedback. I'm going to do the easier stuff
on this list then package it up and send it to you, Jesper, if you have some
time to implement more of your ideas.

Regards,
Matthew

[OJB-developers] JCA implementation comments and ideas

[Jesper L. <je...@da...>]

Hi Matthew, Thomas, all

Sorry for the late reply. Below are my comments on your JCA code Matthew. 
After that I included some additional suggestions and ideas to consider.

Comments:

1) The close() implementation is missing (method empty) in your adapter 
specific connection implementation. The close method must somehow delegated 
to the ManagedConnection implementation and notify all listeners with a 
CONNECTION_CLOSED event. The reason that it seem to work, is because the 
container and connection manager of the application server garbage collects 
unused connection that the user (bean developer) forgets to close.
 
2) The ManagedConnection.destroy() implementation does nothing but setting 
_proxy to null?
 
3) In the client examples provided, there's no call to close() on the 
connection handles???

4) In the non-managed client, you call commit directly on odmg.Transaction?

5) Are you sure your connection handling (i.e. 
OJBMannagedConnection.getConnection) is correctly implemented? I wonder why 
there's no set or anything holding the currently allocated connection 
handles. Are you sure this will work correctly if a bean developer obtains 
multiple connection handles (through OJBConnectionFactory), or if the 
application server uses resource sharing among bean?

A solution may be to implement some kind of session or connection handle 
object (holding a pointer to the actual connection) that is returned from the 
ManagedConnection. This also makes it easier to track what the application 
server is doing in the more complex scenarios. Also, I'm not sure if we can 
avoid this if we allow for resource sharing. At least if you don't support 
resource sharing, you should throw a ResourceException if somebody calls 
getConnection on ManagedConnection multiple times. The problem with resource 
sharing is that we can't really test this on JBoss because the it's current 
connection manager don't support resource sharing yet. So, its important to 
follow the spec here and throw exceptions the right places if we cannot 
handle resource sharing, otherwise we might get in trouble with other 
application servers.

6) In your non-mananaged and managed client scenario, something that I don't 
understand is why does the TestClient and ProductServiceBean work different 
with the resource manager factory (OJBConnectionFactory), i.e one invokes 
createOJBConnection(), the other uses getConnection()? The general idea is 
that the resource manager factory should work the same in non-managed and 
managed scenarios. Also, how is the fine OJBConnectionManager you've created 
ever going to be used if you call createOJBConnection?

7) You've created the resource manager factory using the Common Client 
interface (CCI). I do not quite understand the philosophy behind this 
decision? Can you elaborate why you use CCI.

In the ProductService session bean you do something like this:

String pmname = "java:/OJB"
Object ob = new InitialContext().lookup(pmname);
OJBConnectionFactoryImpl fac = (OJBConnectionFactoryImpl) ob;
Implementation connection = (Implementation) fac.getConnection();
Database db = connection.newDatabase();
..open db, do stuff, and so on

The first question is why the example does not use JNDI ENC and define a 
resource-ref in ejb-jar.xml? I will argue that all EJB examples provided with 
the JCA adapter must do this.

You cast to OJBConnectionFactoryImpl, why?

Moreover, I do not understand why to think of org.odmg.Implementation as a 
connection? That is, I think it would be more intuitive if Implementation was 
the resource factory interface and not the connection handle. Also, what if 
the user creates multiple database connection calling newDatabase, how should 
pooling work then?

8) I don't understand your TransactionDelegate thing. Can you elaborate how 
this is supposed to work and how to use it.


--------


Here's some ideas/suggestions:

1) resource manager factory interface

I would suggest to have a resource manager factory interface for each type of 
persistence API. The factory interfaces will be 
ojb.broker.PersistenceBrokerFactory for OJB "native", org.odmg.Implementation 
for ODMG, and javax.jdo.PersistenceManagerFactory for JDO.In ODMG mode, both 
Implementation, Database and Transaction should be wrapped. The 
org.odmg.Database will map to ManagedConnection.


For example:

OJB:
ctx = new InitialContext();
PersistenceBrokerFactory fac = (PersistenceBrokerFactory) ctx.lookup
( "java:comp/env/ojb/mydb" );
PersistenceBroker broker = fac.createNewBrokerInstance();
/* do stuff */
broker.close();


ODMG:
ctx = new InitialContext();
Implementation odmg = (Implementation) ctx.lookup
( "java:comp/env/odmg/mydb" );
Database db = odmg.newDatabase();
db.open(databaseName, Database.OPEN_READ_WRITE);
Transaction tx = odmg.newTransaction();
/* do stuff */
db.close();


JDO:
ctx = new InitialContext();
PersistenceManagerFactory fac = (PeersistenceManagerFactory) ctx.lookup
( "java:comp/env/jdo/mydb" );
PersistenceManager pm = fac.getPersistenceManager(user, passwd);
/* do stuff */
pm.close();


I think issue on how the resource factory interfaces should work is extremely 
important, and something we must agree on. In the JDO case, there's not so 
much to discuss, because the JDO spec dictates how it should work. However, 
in the other two cases we must discuss and agree on how it should work before 
starting to use the JCA connector for real. Otherwise, it will be very 
difficult to change it later on, and things might get messy. That is, we'll 
get unhappy users, because they have to change their client code.

Another thing, I think it would be cool if the JCA-based factory interfaces 
was the default way to use OJB in non-managed environments in the future. It 
would provide OJB a nice and standard low-level connection and transaction 
mechanism. The idea of having a connection manager with standard interfaces 
is an extremely nice one. This also makes it a lot easier to provide better 
QoS in the connection mechanism by using code (say borrowing ideas) from 
other cool JCA-aware connection manager implementations.

If we used JCA and JTA/XA in the OJB OTM core also, we would more-or-less 
have the generic OTM mechanism Thomas talked about in the JDO proposal. It 
should then be designed to work with OJB, ODMG and JDO on top, and provide 
standard-based connection management (javax.resource.spi package) and 
transaction management (javax.transaction.xa package) in the transaction 
layer below. When running in managed-environments we'll "just" have to switch 
over control to the connection manager in the application server and vice 
versa. This is of course not something needed right away, however I think 
it's good to have this in mind when XA is added to the adapter.


2) Transaction handling

Have you thought about supporting bean-managed transactions as defined in the 
JDO spec in ODMG mode also? 

The idea is, that the user can both use the persistence API(s) transaction 
interface (i.e. org.odmg.Transaction, javax.jdo.Transaction or 
ojb.PersistenceBroker) or UserTransaction directly to demarcate transaction 
in beans with bean-managed transaction. If the persistence specific 
transaction API is used, then the transaction implementation will delegate to 
UserTransaction (see JDO-spec 16.1.3).

I think this is nice because it allows the same code to run in both managed 
and non-managed scenarios without much change. But more important, when 
calling commit/rollback on i.e. org.odmg.Transaction running within a 
container-managed transaction the container will detect this and throw an 
exception!

Not wrapping the ojb.odmg.TransactionImpl the container or JCA adapter will 
not be able to check this, and changes may be committed or rolled back to the 
database even that it's illegal for the user to do this using CMT. This might 
very well screw up things, for example if the container wants to rollback 
later after the user has called commit.

For example in a bean with CMT:

/* user updates stuff */
Transaction tx = odmg.currentTransaction();
tx.commit();
/* 
  now some other code call setRollbackOnly or an unchecked exception 
  is thrown, which means that the container will roll-back the 
  transaction. Not very good, because the stuff is already 
  committed to the database by OJB's transaction manager!!!
*/

------

Other things I would like to discuss also is Resource adapter configuration 
(i.e. when having multiply ManageConnectionFactory configurations/resources-
managers set-up), and how to get JTA/XA into the adapter. XA is a very 
important for me, because of the need to use OJB together with other XA-aware 
resource managers and therefore need 2PC and DTM support. Also, I'm probably 
going to use the stuff in another app-server called Trifork pretty soon. So, 
we'll get the adapter compatibility tested and know if the stuff works on 
other application servers also. 

However, I'll suggest we try discuss and agree on the connection factory 
interfaces and user transaction demarcation first. IMO, this is most 
important right now.

/Jesper

Re: [OJB-developers] [patch] build.xml

[<ri...@ya...>]

Hi,

The released OJB 0.8.375 doesn't build without this diff applied.

Thomas, you should re-release a patched version soon!

Greetings,

Ricardo

----- Original Message -----=20
From: "Thomas Mahler" <tho...@ho...>
To: "Martin Poeschl" <mpo...@ma...>
Cc: <obj...@li...>
Sent: Monday, April 08, 2002 1:28 PM
Subject: Re: [OJB-developers] [patch] build.xml


> thanks,
>=20
> I forgot to check in my changes...
>=20
> Thomas
>=20
> Martin Poeschl wrote:
>=20
> > there still exists a bug in the buil.xml
> >=20
> > a patch is included ;-)
> >=20
> > martin
> >=20
> >=20
> > =
------------------------------------------------------------------------
> >=20
> > Index: build.xml
> > =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> > RCS file: /cvsroot/objectbridge/ojb-1-0/build.xml,v
> > retrieving revision 1.11
> > diff -u -r1.11 build.xml
> > --- build.xml 30 Mar 2002 12:12:52 -0000 1.11
> > +++ build.xml 8 Apr 2002 14:56:18 -0000
> > @@ -1,4 +1,4 @@
> > -<!--=20
> > +<!--
> >  ObJectBridge ANT build configuration.=20
> >       initial author: Thomas Mahler
> >       contains modifications by Chris Greenlee and others.
> > @@ -40,24 +40,25 @@
> >  <!-- Preprocess Java Source Code -->
> >  <target name=3D"preprocess" depends=3D"prepare">
> >          <echo message=3D"using switches: ${JDK}, ${DEBUG}"/>
> > - <java fork=3D"no" classname=3D"org.hsqldb.util.CodeSwitcher" =
failonerror=3D"true" classpath=3D"compilation-classpath">
> > - <arg value=3D"${source}" />
> > -            <arg value=3D"${JDK}" />
> > -            <arg value=3D"${DEBUG}" />
> > - </java>
> > + <java fork=3D"no" classname=3D"org.hsqldb.util.CodeSwitcher" =
failonerror=3D"true">
> > + <arg value=3D"${source}" />
> > + <classpath refid=3D"compilation-classpath" />
> > + <arg value=3D"${JDK}" />
> > + <arg value=3D"${DEBUG}" />
> > + </java>
> >  </target>
> > -=20
> > +
> >      <!-- Delete all the directories created in prepare -->
> >      <target name=3D"clean" depends=3D"init" description=3D"Cleans =
the build and distribution directories.">
> >          <delete dir=3D"${build}" verbose=3D"false"/>
> >          <delete dir=3D"${dist}" verbose=3D"false"/>
> > -    </target>=20
> > -=20
> > +    </target>
> > +
> >      <!-- Build all the sources with debug and deprecation -->
> >      <target name=3D"main" depends=3D"prepare" =
description=3D"Compile all Java sources with debugging on.">
> >          <javac srcdir=3D"${source}" destdir=3D"${classes}" =
excludes=3D"${excludes}" debug=3D"on" deprecation=3D"${deprecation}">
> >          <classpath refid=3D"compilation-classpath" />
> > -        </javac> =20
> > +        </javac>
> >      </target>=20
> > =20
> >      <!-- Same as main, but with cleanup, preprocessing and building =
of oql parser -->
> >=20
> > The command completed successfully.
> >=20
>=20
>=20
>=20
> _______________________________________________
> Objectbridge-developers mailing list
> Obj...@li...
> https://lists.sourceforge.net/lists/listinfo/objectbridge-developers
>=20

RE: [OJB-developers] AW: [Fwd: maven build for ojb]

[Jason v. Z. <jv...@ze...>]

On Wed, 2002-04-10 at 09:20, Chris Greenlee wrote:
> 
> Sweet. :)  One question I had is whether you can specify different
> repositories for looking up dependencies.  I suppose with your access to
> the turbine repository, you can place the OJB dependencies there, but
> with some third-party jars it's always possible they won't allow
> redistribution except from their own site.

These are issues we are trying to deal with in general. There is a
mailing where these issues can be discussed:

http://jakarta.apache.org/turbine/maven/mail-lists.html

We are working on a Java equivalent of CPAN. I have contacted some of
the CPAN fellows and we are going to try and setup a global repository
of Java released JARs, development snapshot JARs and distributions.

We have yet to work out all the details but many projects have started
developing with Maven and we hope that it will take off because it makes
developing easier.

The Maven build and the existing OJB build can live side by side so that
people can continue to use the existing build system if they wish. Maven
is stable and works but we are just about to release a b3 so there are
some issues to work out. Most of these are not technical issues but more
process issues so all feedback is welcome.

For now the only repository for JARs is at Jakarta which shouldn't be a
problem for OSS projects but we are working out the details of for
development teams that work in closed environments. I'm working on this
with David Peugh who is the author of quilt, (quilt.sourceforge.net) a
test coverage tool that will be integrated with Maven, and is working on
several projects (14) at DARPA that are using Maven so we need to work
this out.

I encourage anyone interested to join the Maven mailing lists and get
involved. If Maven improves and many people use Maven then development
processes (building, testing, CI, documentation) should become easier to
manage and we can make our projects better.

> Cheers,
> 
> C.
> 
> > -----Original Message-----
> > From: Jason van Zyl [mailto:jv...@ze...]
> > Sent: Wednesday, April 10, 2002 6:59 AM
> > To: Chris Greenlee
> > Subject: Re: [OJB-developers] AW: [Fwd: maven build for ojb]
> > 
> > 
> > On Wed, 2002-04-10 at 07:57, Chris Greenlee wrote:
> > > 
> > > Jason van Zyl amd I have been working on this too. :)  You 
> > might want to
> > > talk to him to see how far he's gotten -- maybe we can collaborate.
> > > 
> > > Any grunt work you need done, just ask.
> > 
> > Martin works with me @ Zenplex and on Turbine so I asked him 
> > to get the
> > ball rolling. There is a specific format for the 
> > documentation and that
> > needs to be converted from HTML into the xdoc format used by Maven.
> > Maybe you can look for a tool that will take a first pass at 
> > converting
> > the html -> xml.
> > 
> > Maven also has a PDF generator so once the docs are converted we can
> > make a nice PDF manual.
> >  
> > > Cheers,
> > > 
> > > Chris
> > > 
> > > > Hi Martin,
> > > >
> > > >> -------- Original Message --------
> > > >> Subject: maven build for ojb
> > > >> Date: Wed, 10 Apr 2002 01:42:32 +0200
> > > >> From: Martin Poeschl <mpo...@ma...>
> > > >> To: tho...@ho..., Jason van Zyl 
> > <jv...@ze...>
> > > >>
> > > >> i started to do a maven build for ojb
> > > >>
> > > >> i can build the jar and generate some nice docs at the moment
> > > >> see http://alpha.tucana.at/ojb/
> > > >>
> > > >
> > > > Looks really great! I want to have this for OJB!
> > > >
> > > >> i think some dir restructuring is needed to make everything
> > > >> work (e.g.
> > > >> the junit tests)
> > > >>
> > > >
> > > > Please tell me about necessary changes in advance. I want 
> > to understand
> > > > what's going on.
> > > >
> > > >> thomas if you grant write access to me i can do the job ;-)
> > > >
> > > > I just enabled your account for CVS access!
> > > >
> > > >> i'll also make sure the old build system is still 
> > working afer the
> > > >> changes (if you want to keep it)
> > > >>
> > > >
> > > > Yes, that would be good at least for the migration phase.
> > > >
> > > >> martin
> > > >>
> > > >>
> > > >>
> > > >>
> > > >>
> > > >
> > > > _______________________________________________
> > > > Objectbridge-developers mailing list
> > > > Obj...@li...
> > > > 
> https://lists.sourceforge.net/lists/listinfo/objectbridge-developers
> > 
> > 201
> > 
> > 
> > 
> > 
> > _______________________________________________
> > Objectbridge-developers mailing list
> > Obj...@li...
> > https://lists.sourceforge.net/lists/listinfo/objectbridge-developers
> -- 
> jvz.
> 
> Jason van Zyl
> jv...@ap...
> 
> http://tambora.zenplex.org
-- 
jvz.

Jason van Zyl
jv...@ap...

http://tambora.zenplex.org

Re: [OJB-developers] AW: [Fwd: maven build for ojb]

[Chris G. <CGr...@de...>]

Jason van Zyl amd I have been working on this too. :)  You might want to
talk to him to see how far he's gotten -- maybe we can collaborate.

Any grunt work you need done, just ask.

Cheers,

Chris

> Hi Martin,
>
>> -------- Original Message --------
>> Subject: maven build for ojb
>> Date: Wed, 10 Apr 2002 01:42:32 +0200
>> From: Martin Poeschl <mpo...@ma...>
>> To: tho...@ho..., Jason van Zyl <jv...@ze...>
>>
>> i started to do a maven build for ojb
>>
>> i can build the jar and generate some nice docs at the moment
>> see http://alpha.tucana.at/ojb/
>>
>
> Looks really great! I want to have this for OJB!
>
>> i think some dir restructuring is needed to make everything
>> work (e.g.
>> the junit tests)
>>
>
> Please tell me about necessary changes in advance. I want to understand
> what's going on.
>
>> thomas if you grant write access to me i can do the job ;-)
>
> I just enabled your account for CVS access!
>
>> i'll also make sure the old build system is still working afer the
>> changes (if you want to keep it)
>>
>
> Yes, that would be good at least for the migration phase.
>
>> martin
>>
>>
>>
>>
>>
>
> _______________________________________________
> Objectbridge-developers mailing list
> Obj...@li...
> https://lists.sourceforge.net/lists/listinfo/objectbridge-developers

201

[OJB-developers] RE: Persistence for the oJB Mapping Repository

[Florian B. <bf...@fl...>]

Hi Thomas,

great to hear! I'll try to do it over the weekend.

best regards,
Florian

-----Original Message-----
From: Mahler Thomas [mailto:tho...@it...]
Sent: Wednesday, April 10, 2002 1:15 PM
To: Florian Bruckner (E-Mail); Objectbridge (E-Mail)
Subject: Persistence for the oJB Mapping Repository


Hi Florian, hi all,

I just completed the ojb.broker.metadata.RepositoryPersistor and checked it
into CVS.
This class allow to read DescriptorRepository Objects from XML files AND to
write them back into xml Files.

Benefits:
- information on XML grammar is kept in single point.
- changing the repository.dtd will be much simpler.
- writing mapping tools will be much simpler now, as all mapping related
tools (as your reversedb) work directly on DescriptorRepository objects.

Florian, there is now no more need to have your tool directly generate XML
files! You can start to refactor you reversedb tool to use the persistor.

cu,

Thomas

[OJB-developers] Persistence for the oJB Mapping Repository

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

Hi Florian, hi all,
 
I just completed the ojb.broker.metadata.RepositoryPersistor and checked it
into CVS.
This class allow to read DescriptorRepository Objects from XML files AND to
write them back into xml Files.
 
Benefits:
- information on XML grammar is kept in single point. 
- changing the repository.dtd will be much simpler.
- writing mapping tools will be much simpler now, as all mapping related
tools (as your reversedb) work directly on DescriptorRepository objects. 
 
Florian, there is now no more need to have your tool directly generate XML
files! You can start to refactor you reversedb tool to use the persistor.
 
cu,
 
Thomas
 

[OJB-developers] AW: [Fwd: maven build for ojb]

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

Hi Martin,

> -------- Original Message --------
> Subject: maven build for ojb
> Date: Wed, 10 Apr 2002 01:42:32 +0200
> From: Martin Poeschl <mpo...@ma...>
> To: tho...@ho..., Jason van Zyl <jv...@ze...>
> 
> i started to do a maven build for ojb
> 
> i can build the jar and generate some nice docs at the moment
> see http://alpha.tucana.at/ojb/
>

Looks really great! I want to have this for OJB!
 
> i think some dir restructuring is needed to make everything 
> work (e.g. 
> the junit tests)
> 

Please tell me about necessary changes in advance. I want to understand
what's going on.

> thomas if you grant write access to me i can do the job ;-)

I just enabled your account for CVS access!

> i'll also make sure the old build system is still working afer the 
> changes (if you want to keep it)
> 

Yes, that would be good at least for the migration phase.

> martin
> 
> 
> 
> 
> 

AW: [Fwd: RE: [OJB-developers] Mapping Question]

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

Hi Vikas,

> 
> I hope this time I am posting my question on the right mailing list.
> 
> Thomas, thank you so much for your reply to my original question on 
> Developer's mailing list.  However, I am still not clear.  I read 
> tutorial3.html and it does pretty good job of explaining inheritance 
> mapping.  My situation has additional quirk of relation 
> mapping.  Let me 
> try to explain..........
> 
>  >From the classes point of view: there is class M with attributes as 
> follows:
> 
> Class M
> ---------
> m_id                   integer
> someValue          String
> child_type           String
> child_id              integer
>


Does one M instance have a D attribute ?
m_myD		D ?
 
> There is Class D and subclasses D1,D2,D3... (that need persistence)
> 
> Class D
> ---------
> child_id                       integer
> someData                   String
> 
> class D1
> ----------
> child_id                  integer
> aaValue                  String
> bbValue                  String
> 
> 
> Class D2
> ------------
> child_id                 integer
> ccValue                 String
> ddValue                 String
> 
> Class D3
> ------------
> child_id                 integer
> eeValue                 String
> ffValue                 String
> 
> The relation ship between M and instance of D (really D1 or 
> D2 or D3) is 
> determined by 'child_type' of class M.
> 
> I understand inheritance mapping of class D and subclasses 
> D1,D2,D3.  I 
> am leaning towards mapping each subclass with distinct table (with 
> FieldDescriptor for all attributes including inherited 
> attributes).  How 
> do I map the relationship between M and D1,D2,D3 as they are 
> joined by 
> child_id to the appropriate table based on value of 'child_type'.
> 

OJB supports polymorphism. That is you simply declare that M has a reference
attribute of type D.
To enable polymorph loading of D instances you must declare an extent for
Class D that contains classes D1, D2, D3.
This is also explained in Tutorial 3
(http://objectbridge.sourceforge.net/tutorial3.html#extents-and-polymorphism
). There is also plenty of sample code for similar problems in the
test.ojb.broker package.
The attribute child_type is not needed for OJB.

HTH,

Thomas

> Does this make sense?
> 
> Thanks for any help you can provide.
> 
> Vikas
> 
> 
> 
> 
> -----Original Message-----
> From: Thomas Mahler [mailto:tho...@ho...]
> Sent: Thursday, April 04, 2002 2:22 AM
> To: Vikas Javiya
> Cc: obj...@li...
> Subject: Re: [OJB-developers] Mapping Question
> 
> 
> Hi Vikas,
> 
> please refer to the tutorial3.html. It explains how to build mappings
> for inheritance hierarchies.
> It also explains how mappings for 1:1, 1:n and m:n 
> associations are build.
> 
> If you have further question that are not answered in the mentioned
> document don't hesitate to post your questions to the 
> objectbridge-users
> mailinglist.
> 
> 
> HTH,
> Thomas
> 
> Vikas Javiya wrote:
> 
>  > Hello,
>  >
>  >
>  >
>  > A simple question regarding mapping;
>  >
>  >
>  >
>  > I have a class operation and a table OPERATION for 
> persistence.  Two
>  > main attributes of operation are; resource_type and resource_id.
>  > Possible values for resource_type are 'Phone_number' , 
> 'Email_address',
>  > 'JMS_Queue', 'EJB_methods'.  There is class 'resource' and 
> sub classes
>  > 'Phone_resource', 
> 'email_resource','JMS_resource','EJB_resource'.  There
>  > are tables to map all of these sub classes of resource.  
> An OPERATION
>  > table is linked to any of these resource table via 
> resource_ID column
>  > depending on the resource_type column.  In a way it is 
> dynamic mapping
>  > between 'operation' class and any of the resource classes 
> based on the
>  > value of resource_type.
>  >
>  >
>  >
>  > How do I map this in repository.xml??????????????
>  >
>  >
>  >
>  > Thanks for your help.
>  >
>  >
>  >
>  > Vikas
>  >
>  >
>  >
>  >
>  >
>  > Vikas Javiya
>  >
>  > ThatOne Company
>  >
>  > 408.869.8112 (Phone)
>  >
>  > 408.487.9801 (Fax)
>  >
>  > www.ThatOne.com <http://www.thatone.com/>
>  >
>  > 
> --------------------------------------------------------------
> ----------
>  >
>  > The information transmitted is intended only for the 
> person or entity to
>  > which it is addressed and may contain confidential and/or 
> privileged
>  > material. Any review, retransmission, dissemination or 
> other use of, or
>  > taking of any action in reliance upon, this information by 
> persons or
>  > entities other than the intended recipient is prohibited. If you
>  > received this in error, please contact the sender and delete the
>  > material from any computer.
>  >
>  > 
> --------------------------------------------------------------
> ----------
>  >
>  >
>  >
>  >
>  >
> 
> 
> 
> 
> 
> 

Re: [OJB-developers] [patch] tutorial scripts

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

thanks !

Martin Poeschl wrote:

> attached are the patches to make the turorial scripts work
> 
> martin
> 
> 
> ------------------------------------------------------------------------
> 
> Index: tutorial1.bat
> ===================================================================
> RCS file: /cvsroot/objectbridge/ojb-1-0/tutorial1.bat,v
> retrieving revision 1.1.1.1
> diff -u -r1.1.1.1 tutorial1.bat
> --- tutorial1.bat	15 Feb 2002 06:21:39 -0000	1.1.1.1
> +++ tutorial1.bat	8 Apr 2002 22:40:08 -0000
> @@ -1,5 +1,5 @@
>  cd build\test\ojb
> -java -cp .;../../../lib/log4j.jar;../../../lib/hsqldb.jar;../../../lib/jta-spec1_0_1.jar;../../../lib/jaxp.jar;../../../lib/parser.jar;../../classes test.ojb.tutorial1.Application
> +java -cp .;../../../lib/log4j.jar;../../../lib/hsqldb.jar;../../../lib/jta-spec1_0_1.jar;../../../lib/crimson.jar;../../classes test.ojb.tutorial1.Application
>  
>  cd..
>  cd..
> Index: tutorial1.sh
> ===================================================================
> RCS file: /cvsroot/objectbridge/ojb-1-0/tutorial1.sh,v
> retrieving revision 1.2
> diff -u -r1.2 tutorial1.sh
> --- tutorial1.sh	15 Mar 2002 14:30:33 -0000	1.2
> +++ tutorial1.sh	8 Apr 2002 22:40:08 -0000
> @@ -3,6 +3,6 @@
>  
>  cd build/test/ojb
>  
> -java -cp .:../../../lib/jdbc2_0-stdext.jar:../../../lib/log4j.jar:../../../lib/hsqldb.jar:../../../lib/jta-spec1_0_1.jar:../../../lib/jaxp.jar:../../../lib/parser.jar:../../classes test.ojb.tutorial1.Application
> +java -cp .:../../../lib/jdbc2_0-stdext.jar:../../../lib/log4j.jar:../../../lib/hsqldb.jar:../../../lib/jta-spec1_0_1.jar:../../../lib/crimson.jar:../../classes test.ojb.tutorial1.Application
>  
>  
> Index: tutorial2.bat
> ===================================================================
> RCS file: /cvsroot/objectbridge/ojb-1-0/tutorial2.bat,v
> retrieving revision 1.1.1.1
> diff -u -r1.1.1.1 tutorial2.bat
> --- tutorial2.bat	15 Feb 2002 06:21:39 -0000	1.1.1.1
> +++ tutorial2.bat	8 Apr 2002 22:40:08 -0000
> @@ -1,5 +1,5 @@
>  cd build\test\ojb
> -java -cp .;../../../lib/log4j.jar;../../../lib/antlr.jar;../../../lib/hsqldb.jar;../../../lib/jta-spec1_0_1.jar;../../../lib/jaxp.jar;../../../lib/parser.jar;../../classes test.ojb.tutorial2.Application
> +java -cp .;../../../lib/log4j.jar;../../../lib/antlr.jar;../../../lib/hsqldb.jar;../../../lib/jta-spec1_0_1.jar;../../../lib/crimson.jar;../../../lib/jdbc2_0-stdext.jar;../../classes test.ojb.tutorial2.Application
>  
>  cd..
>  cd..
> Index: tutorial2.sh
> ===================================================================
> RCS file: /cvsroot/objectbridge/ojb-1-0/tutorial2.sh,v
> retrieving revision 1.1.1.1
> diff -u -r1.1.1.1 tutorial2.sh
> --- tutorial2.sh	15 Feb 2002 06:21:39 -0000	1.1.1.1
> +++ tutorial2.sh	8 Apr 2002 22:40:08 -0000
> @@ -4,6 +4,6 @@
>  cd build/test/ojb
>  pwd
>  
> -java -cp .:../../../lib/log4j.jar:../../../lib/antlr.jar:../../../lib/hsqldb.jar:../../../lib/jta-spec1_0_1.jar:../../../lib/jaxp.jar:../../../lib/parser.jar:../../classes test.ojb.tutorial2.Application
> +java -cp .:../../../lib/log4j.jar:../../../lib/antlr.jar:../../../lib/hsqldb.jar:../../../lib/jta-spec1_0_1.jar:../../../lib/crimson.jar:../../../lib/jdbc2_0-stdext.jar:../../classes test.ojb.tutorial2.Application
>  
>  
> 

[OJB-developers] [patch] tutorial scripts

[Martin P. <mpo...@ma...>]

attached are the patches to make the turorial scripts work

martin