You are viewing a plain text version of this content. The canonical link for it is here.
Posted to ojb-user@db.apache.org by Michael Mogley <mm...@adelphia.net> on 2004/02/29 04:39:57 UTC
using single persistence broker instance
I was wondering if anyone out there could comment on my usage of PersistenceBroker in an EJB. I currently create a single instance during ejbCreate and keep it for the duration of the bean's lifecycle. This seems like the most efficient way. Is there a danger to using this approach when transactions and distributed caches are involved? Any other potential pitfalls?
Just want to make sure I'm not asking for trouble down the road.
Thanks,
Michael
Re: using single persistence broker instance
Posted by Michael Mogley <mm...@adelphia.net>.
> > Are you saying the connection must be released for read-only operations?
I
> > am not understanding. Is there some danger to keeping a connection
> > constantly open (so long as serial access is ensured)?
> >
>
> The connection/DataSource handle could get timed out and PB show
> unexpected behaviour. Could be a performance issue, hundered open
> connections (each bean has a bean pool and each bean may have an open
> connection). Your appServer connection pool could exhaust.
I see. I forgot about the bean pool. But the timeout issue could be dealt
with easily enough. For instance, in MySQL, you can set an autoreconnect
flag to have timed-out connection come alive on subsequent access.
MIchael
> regards,
> Armin
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-user-help@db.apache.org
Re: using single persistence broker instance
Posted by Armin Waibel <ar...@apache.org>.
Michael Mogley wrote:
>>EJB. I currently create a single instance during ejbCreate and keep it
>>for the duration of
>>the bean's lifecycle. This seems like the most efficient way. Is there
>>a danger to using
>>this approach when transactions and distributed caches are involved?
>>Any other potential pitfalls?
>>
>>There could be a problem with the used connections when read-only
>>operations (without tx-demarction) were performed. PB instance obtain a
>>connection when needed. On PB.commitTransaction/abortTransaction
>>(internal called in managed environments) and PB.close the connection
>>was released.
>
>
> Are you saying the connection must be released for read-only operations? I
> am not understanding. Is there some danger to keeping a connection
> constantly open (so long as serial access is ensured)?
>
The connection/DataSource handle could get timed out and PB show
unexpected behaviour. Could be a performance issue, hundered open
connections (each bean has a bean pool and each bean may have an open
connection). Your appServer connection pool could exhaust.
regards,
Armin
> Michael
>
>
>>On read-only operations (no cm-tx or bm-tx used/required) only on
>>PB.close the connection was released. In your case the association
>>between PB instance and connection may not be detached. You can do this
>>manually by calling PB.serviceConnectionManager().releaseConnection()
>>for read-only methods, but I don't recommend this when using cm-tx,
>>because tx declaration in DD may change and I'm not sure if this could
>>cause side-effects.
>>
>>regards,
>>Armin
>>
>>
>>>Just want to make sure I'm not asking for trouble down the road.
>>>
>>>Thanks,
>>>
>>>Michael
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
>>For additional commands, e-mail: ojb-user-help@db.apache.org
>>
>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-user-help@db.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-user-help@db.apache.org
Re: using single persistence broker instance
Posted by Michael Mogley <mm...@adelphia.net>.
Hi Armin,
> Hi Michael,
>
> Michael Mogley wrote:
> > I was wondering if anyone out there could comment on my usage of
PersistenceBroker in an
> EJB. I currently create a single instance during ejbCreate and keep it
> for the duration of
> the bean's lifecycle. This seems like the most efficient way. Is there
> a danger to using
> this approach when transactions and distributed caches are involved?
> Any other potential pitfalls?
> >
>
> There could be a problem with the used connections when read-only
> operations (without tx-demarction) were performed. PB instance obtain a
> connection when needed. On PB.commitTransaction/abortTransaction
> (internal called in managed environments) and PB.close the connection
> was released.
Are you saying the connection must be released for read-only operations? I
am not understanding. Is there some danger to keeping a connection
constantly open (so long as serial access is ensured)?
Michael
> On read-only operations (no cm-tx or bm-tx used/required) only on
> PB.close the connection was released. In your case the association
> between PB instance and connection may not be detached. You can do this
> manually by calling PB.serviceConnectionManager().releaseConnection()
> for read-only methods, but I don't recommend this when using cm-tx,
> because tx declaration in DD may change and I'm not sure if this could
> cause side-effects.
>
> regards,
> Armin
>
> > Just want to make sure I'm not asking for trouble down the road.
> >
> > Thanks,
> >
> > Michael
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-user-help@db.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-user-help@db.apache.org
Re: using single persistence broker instance
Posted by Armin Waibel <ar...@apache.org>.
Hi Michael,
Michael Mogley wrote:
> I was wondering if anyone out there could comment on my usage of PersistenceBroker in an
EJB. I currently create a single instance during ejbCreate and keep it
for the duration of
the bean's lifecycle. This seems like the most efficient way. Is there
a danger to using
this approach when transactions and distributed caches are involved?
Any other potential pitfalls?
>
There could be a problem with the used connections when read-only
operations (without tx-demarction) were performed. PB instance obtain a
connection when needed. On PB.commitTransaction/abortTransaction
(internal called in managed environments) and PB.close the connection
was released.
On read-only operations (no cm-tx or bm-tx used/required) only on
PB.close the connection was released. In your case the association
between PB instance and connection may not be detached. You can do this
manually by calling PB.serviceConnectionManager().releaseConnection()
for read-only methods, but I don't recommend this when using cm-tx,
because tx declaration in DD may change and I'm not sure if this could
cause side-effects.
regards,
Armin
> Just want to make sure I'm not asking for trouble down the road.
>
> Thanks,
>
> Michael
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-user-help@db.apache.org
Re: AW: Extent
Posted by Peter Wieland <pe...@gmx.de>.
Hi Dirk,
sorry, no idea how to use this with XDoclet. I pass on the question to the
community.
We use AXgen to generate everything based on an UML metamodel...
Peter
> Hi Peter,
> my first repository-user.xml does not contain the extent concept at all. I
> simply did not set up a class-descriptor for BaseClass - just as you
> described.
> The extent concept came up to my mind when I thought that XDoclet would be
> a
> great time saver to set up the repository. For each attribute in the model
> class you declare an ojb.field, ojb.reference etc. Since the common
> attributes are in BaseClass I wondered how to set them up via XDoclet for
> each model class. That is why I guess U have to use the extent concept of
> ojb.
> Any idea?
> Dirk
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-user-help@db.apache.org
AW: AW: AW: Extent
Posted by "Dirk Manske (Service Respond)" <se...@nexgo.de>.
hm. in my last download of ojb-1.0rc5 (dec. 2003) there was no docu about
the xdoclet support. however I got it from the cvs version and it works
now. thanks.
Dirk
-----Ursprüngliche Nachricht-----
Von: Thomas Dudziak [mailto:tomdz@first.gmd.de]
Gesendet: Dienstag, 2. März 2004 10:54
An: OJB Users List
Betreff: Re: AW: AW: Extent
On Tue, 2 Mar 2004, Dirk Manske (Service Respond) wrote:
> thanks for the answer Tom. I need more information about the
> ojb.modify-inherited tag. You say I could control which attribute will
> be picked up. How? Here is the scenario: The BaseClass holds all the
> "common attributes". For some objects (extended from BaseClass) all
> these common attributes have to be persisted while for some other
> objects (also extended from BaseClass) only a few of them have to be
> persisted. The problem is, that the generated repository now holds all
> the common attributes for each class-descriptor but I do not need them
> for each class. could the ojb.modify-inherited tag help me in this
> case? An example of how to exclude an attribute for specific classes
> would be great. thx,
There is one in the docs for the xdoclet-module. Bascially, you state the
inherited feature that you want to modify (via the name) and then you have
'ignore="true"' for it.
You should be careful with modification (though ignore should be safe) as
the xdoclet-module probably allows far more than OJB.
Tom
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-user-help@db.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-user-help@db.apache.org
Re: AW: AW: Extent
Posted by Thomas Dudziak <to...@first.gmd.de>.
On Tue, 2 Mar 2004, Dirk Manske (Service Respond) wrote:
> thanks for the answer Tom. I need more information about the
> ojb.modify-inherited tag. You say I could control which attribute will be
> picked up. How? Here is the scenario: The BaseClass holds all the "common
> attributes". For some objects (extended from BaseClass) all these common
> attributes have to be persisted while for some other objects (also extended
> from BaseClass) only a few of them have to be persisted. The problem is,
> that the generated repository now holds all the common attributes for each
> class-descriptor but I do not need them for each class. could the
> ojb.modify-inherited tag help me in this case? An example of how to exclude
> an attribute for specific classes would be great. thx,
There is one in the docs for the xdoclet-module. Bascially, you state the
inherited feature that you want to modify (via the name) and then you
have 'ignore="true"' for it.
You should be careful with modification (though ignore should be safe) as
the xdoclet-module probably allows far more than OJB.
Tom
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-user-help@db.apache.org
AW: AW: Extent
Posted by "Dirk Manske (Service Respond)" <se...@nexgo.de>.
thanks for the answer Tom. I need more information about the
ojb.modify-inherited tag. You say I could control which attribute will be
picked up. How? Here is the scenario: The BaseClass holds all the "common
attributes". For some objects (extended from BaseClass) all these common
attributes have to be persisted while for some other objects (also extended
from BaseClass) only a few of them have to be persisted. The problem is,
that the generated repository now holds all the common attributes for each
class-descriptor but I do not need them for each class. could the
ojb.modify-inherited tag help me in this case? An example of how to exclude
an attribute for specific classes would be great. thx,
Dirk
-----Ursprüngliche Nachricht-----
Von: Thomas Dudziak [mailto:tomdz@first.gmd.de]
Gesendet: Sonntag, 29. Februar 2004 21:03
An: OJB Users List
Betreff: Re: AW: Extent
On Sun, 29 Feb 2004, Dirk Manske (Service Respond) wrote:
> Hi Peter,
>
> my first repository-user.xml does not contain the extent concept at
> all. I simply did not set up a class-descriptor for BaseClass - just
> as you described.
>
> The extent concept came up to my mind when I thought that XDoclet
> would be a great time saver to set up the repository. For each
> attribute in the model class you declare an ojb.field, ojb.reference
> etc. Since the common attributes are in BaseClass I wondered how to
> set them up via XDoclet for each model class. That is why I guess U have
to use the extent concept of
> ojb.
Simply put the required tags (ojb.field, ojb.reference etc.) in the
BaseClass. There is no need to tag the BaseClass with ojb.class, the XDoclet
module will pick up any inherited persistent (tagged) features regardless of
whether their class is persistent (ojb.class) or not, and add them to the
current class descriptor. You can also control which features are picked up
via the ojb.modify-inherited tag, which also allows you to modify them for
the current class.
Tom
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-user-help@db.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-user-help@db.apache.org
Re: AW: Extent
Posted by Thomas Dudziak <to...@first.gmd.de>.
On Sun, 29 Feb 2004, Dirk Manske (Service Respond) wrote:
> Hi Peter,
>
> my first repository-user.xml does not contain the extent concept at all. I
> simply did not set up a class-descriptor for BaseClass - just as you
> described.
>
> The extent concept came up to my mind when I thought that XDoclet would be a
> great time saver to set up the repository. For each attribute in the model
> class you declare an ojb.field, ojb.reference etc. Since the common
> attributes are in BaseClass I wondered how to set them up via XDoclet for
> each model class. That is why I guess U have to use the extent concept of
> ojb.
Simply put the required tags (ojb.field, ojb.reference etc.) in the
BaseClass. There is no need to tag the BaseClass with ojb.class, the
XDoclet module will pick up any inherited persistent (tagged) features
regardless of whether their class is persistent (ojb.class) or not, and
add them to the current class descriptor. You can also control which
features are picked up via the ojb.modify-inherited tag, which also allows
you to modify them for the current class.
Tom
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-user-help@db.apache.org
AW: Extent
Posted by "Dirk Manske (Service Respond)" <se...@nexgo.de>.
Hi Peter,
my first repository-user.xml does not contain the extent concept at all. I
simply did not set up a class-descriptor for BaseClass - just as you
described.
The extent concept came up to my mind when I thought that XDoclet would be a
great time saver to set up the repository. For each attribute in the model
class you declare an ojb.field, ojb.reference etc. Since the common
attributes are in BaseClass I wondered how to set them up via XDoclet for
each model class. That is why I guess U have to use the extent concept of
ojb.
Any idea?
Dirk
-----Ursprüngliche Nachricht-----
Von: Peter Wieland [mailto:peter.wieland@gmx.de]
Gesendet: Sonntag, 29. Februar 2004 16:47
An: ojb-user@db.apache.org
Betreff: Re: Extent
Hi Dirk,
I'm not sure whether I understood your problem. Maybe I can help anyway...
First, I'm not sure whether you really need to declare the extents for all
your classes. Wouldn't it be sufficient to simply have all model classes
having the same superclass BaseClass. If this is the case, simply model
write a class-descriptor for each model class without any extent
declarations. The BaseClass doesn't even need an entry in the repository
file.
Of course, if you need to do queries using the BaseClass, this approach
won't work. You would then need to declare the BaseClass in the repository
with all it's extents. This would probably look like
<class-descriptor class="foo.bar.BaseClass">
<extent-class class-ref="foo.bar.ModelClass1"/>
<extent-class class-ref="foo.bar.ModelClass2"/>
...
<extent-class class-ref="foo.bar.ModelClassN"/>
<field-descriptor autoincrement="true" primarykey="true" column="id"
jdbc-type="VARCHAR" name="id"/>
<field-descriptor column="version" jdbc-type="VARCHAR" name="version"/>
</class-descriptor>
In the latter case, I think you would have to redeclare the id and version
fields in each extent class together with the specific attributes for each
extent class:
<class-descriptor class="foo.bar.ModelClass1">
<field-descriptor autoincrement="true" primarykey="true" column="id"
jdbc-type="VARCHAR" name="id"/>
<field-descriptor column="version" jdbc-type="VARCHAR" name="version"/>
<field-descriptor column="fieldAFromClass1" jdbc-type="VARCHAR"
name="fieldAFromClass1"/>
<field-descriptor column="fieldBFromClass1" jdbc-type="VARCHAR"
name="fieldBFromClass1"/>
</class-descriptor>
I'm not quite sure, whether it is really necessary to redeclare the common
fields in each extent class, but I'm sure that it works this way as we are
using this approach. The column names for the extent classes do not need to
be the same for the same fields in different extent classes.
Using the extent-approach, you will have one separate table for each model
class, containing all the needed columns, included the "inherited" ones.
Hope that helps,
Peter
> Hi,
> I am using PB-API and DB2 7 for a few weeks now and have a question
> regarding the ojb extent concept.
> I have a BaseClass which holds common attributes (timestamp,
> versionnr) for model objects. Each model class has to extent
> BaseClass. Database tables hold the common attributes and specific
> attributes for the appropriate model class.
> In the repository-user.xml I declared the common attributes separately
> for each model class-descriptor. My question is: Did I miss the
> ojb-extent concept totally? Could I just declare a model class as an
> extent-class of BaseClass and delete the common attributes from each
> (model)class-descriptor because of the extent, ojb would handle these
> attributes automatically for each extended class?
> thx,
> Dirk
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-user-help@db.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-user-help@db.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-user-help@db.apache.org
Re: Extent
Posted by Peter Wieland <pe...@gmx.de>.
Hi Dirk,
I'm not sure whether I understood your problem. Maybe I can help anyway...
First, I'm not sure whether you really need to declare the extents for all
your classes. Wouldn't it be sufficient to simply have all model classes
having the same superclass BaseClass. If this is the case, simply model
write a class-descriptor for each model class without any extent
declarations. The BaseClass doesn't even need an entry in the repository
file.
Of course, if you need to do queries using the BaseClass, this approach
won't work. You would then need to declare the BaseClass in the repository
with all it's extents. This would probably look like
<class-descriptor class="foo.bar.BaseClass">
<extent-class class-ref="foo.bar.ModelClass1"/>
<extent-class class-ref="foo.bar.ModelClass2"/>
...
<extent-class class-ref="foo.bar.ModelClassN"/>
<field-descriptor autoincrement="true" primarykey="true" column="id"
jdbc-type="VARCHAR" name="id"/>
<field-descriptor column="version" jdbc-type="VARCHAR" name="version"/>
</class-descriptor>
In the latter case, I think you would have to redeclare the id and version
fields in each extent class together with the specific attributes for each
extent class:
<class-descriptor class="foo.bar.ModelClass1">
<field-descriptor autoincrement="true" primarykey="true" column="id"
jdbc-type="VARCHAR" name="id"/>
<field-descriptor column="version" jdbc-type="VARCHAR" name="version"/>
<field-descriptor column="fieldAFromClass1" jdbc-type="VARCHAR"
name="fieldAFromClass1"/>
<field-descriptor column="fieldBFromClass1" jdbc-type="VARCHAR"
name="fieldBFromClass1"/>
</class-descriptor>
I'm not quite sure, whether it is really necessary to redeclare the common
fields in each extent class, but I'm sure that it works this way as we are
using this approach. The column names for the extent classes do not need to
be the same for the same fields in different extent classes.
Using the extent-approach, you will have one separate table for each model
class, containing all the needed columns, included the "inherited" ones.
Hope that helps,
Peter
> Hi,
> I am using PB-API and DB2 7 for a few weeks now and have a question
> regarding the ojb extent concept.
> I have a BaseClass which holds common attributes (timestamp, versionnr)
> for
> model objects. Each model class has to extent BaseClass. Database tables
> hold the common attributes and specific attributes for the appropriate
> model
> class.
> In the repository-user.xml I declared the common attributes separately for
> each model class-descriptor. My question is: Did I miss the ojb-extent
> concept totally? Could I just declare a model class as an extent-class of
> BaseClass and delete the common attributes from each
> (model)class-descriptor
> because of the extent, ojb would handle these attributes automatically for
> each extended class?
> thx,
> Dirk
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-user-help@db.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-user-help@db.apache.org
Extent
Posted by "Dirk Manske (Service Respond)" <se...@nexgo.de>.
Hi,
I am using PB-API and DB2 7 for a few weeks now and have a question
regarding the ojb extent concept.
I have a BaseClass which holds common attributes (timestamp, versionnr) for
model objects. Each model class has to extent BaseClass. Database tables
hold the common attributes and specific attributes for the appropriate model
class.
In the repository-user.xml I declared the common attributes separately for
each model class-descriptor. My question is: Did I miss the ojb-extent
concept totally? Could I just declare a model class as an extent-class of
BaseClass and delete the common attributes from each (model)class-descriptor
because of the extent, ojb would handle these attributes automatically for
each extended class?
thx,
Dirk
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-user-help@db.apache.org