Re: Best practice for using ODMG with EJB? (Cache also)
That is kind of what I assumed. It makes using proxies somewhat worthless in an EJB environment, at least in my opinion. Proxies to me seemed to be a great way to do lazy instantiation, and keep the client ignorant of persistence mechanisms. So, if you have to materialize the entire graph before serialization, then you really don't gain anything. Instead of materializing the whole graph, one could also set these objects to null or some instantiation of a class known to the client. Then the client doesn't need to know about OJB at least. But it does mean that the client can't be "ignorant". My graphs can be large enough to overwhelm the client, so I find that using proxies, in spite of these drawbacks, is crucial. Proxies will be also unavoidable when the complexity of the querying I need to do to keep up with reporting needs become more demanding. And I'd rather not consider for the moment multiple repository_user settings (i.e. defining classes in be proxied in one context and non-proxied in another)... Phil Thanks for the response! -Original Message- From: Phil Warrick [mailto:[EMAIL PROTECTED] Sent: Friday, October 17, 2003 11:01 AM To: OJB Users List Subject: Re: Best practice for using ODMG with EJB? (Cache also) Hi Andrew, All that leads me to another question that I don't seem to find an answer to: if a remote EJB passes off an OJB dataobject, I would assume you cannot use any proxies because it would not be able to walk back across the wire, correct? I am currently not making use of any proxies because of that assumption. Seems to me that proxies don't fit well at all with EJB's. You can use proxies with EJB across the wire (I do, in ODMG mode), but the downside is that the client must never try to materialize them and the client needs to be OJB-aware. Before dereferencing a proxied object on the client side, care must be taken to ensure that they have been materialized on the server before serialization. There is a tradeoff here in controlling object-graph size with proxies on the one hand, and transparency of access to persistent classes--regardless of whether the JVM is local or remote--on the other. Removing the need for the client to be OJB-aware could be resolved at either the OJB level or in your application by altering serialization code (writeObject()/readObject() methods I believe) for your persistent classes, to replace any proxies with something else. But in this scenario the client still needs to be concerned with delegating to the server any materialization of associated objects that must be accessed. There has been some discussion from time to time on improving this. Phil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Best practice for using ODMG with EJB? (Cache also)
That is kind of what I assumed. It makes using proxies somewhat worthless in an EJB environment, at least in my opinion. Proxies to me seemed to be a great way to do lazy instantiation, and keep the client ignorant of persistence mechanisms. So, if you have to materialize the entire graph before serialization, then you really don't gain anything. Thanks for the response! -Original Message- From: Phil Warrick [mailto:[EMAIL PROTECTED] Sent: Friday, October 17, 2003 11:01 AM To: OJB Users List Subject: Re: Best practice for using ODMG with EJB? (Cache also) Hi Andrew, > All that leads me to another question that I don't seem to find an > answer > to: if a remote EJB passes off an OJB dataobject, I would assume you cannot > use any proxies because it would not be able to walk back across the wire, > correct? I am currently not making use of any proxies because of that > assumption. Seems to me that proxies don't fit well at all with EJB's. You can use proxies with EJB across the wire (I do, in ODMG mode), but the downside is that the client must never try to materialize them and the client needs to be OJB-aware. Before dereferencing a proxied object on the client side, care must be taken to ensure that they have been materialized on the server before serialization. There is a tradeoff here in controlling object-graph size with proxies on the one hand, and transparency of access to persistent classes--regardless of whether the JVM is local or remote--on the other. Removing the need for the client to be OJB-aware could be resolved at either the OJB level or in your application by altering serialization code (writeObject()/readObject() methods I believe) for your persistent classes, to replace any proxies with something else. But in this scenario the client still needs to be concerned with delegating to the server any materialization of associated objects that must be accessed. There has been some discussion from time to time on improving this. Phil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Best practice for using ODMG with EJB? (Cache also)
Hi Andrew, All that leads me to another question that I don't seem to find an answer to: if a remote EJB passes off an OJB dataobject, I would assume you cannot use any proxies because it would not be able to walk back across the wire, correct? I am currently not making use of any proxies because of that assumption. Seems to me that proxies don't fit well at all with EJB's. You can use proxies with EJB across the wire (I do, in ODMG mode), but the downside is that the client must never try to materialize them and the client needs to be OJB-aware. Before dereferencing a proxied object on the client side, care must be taken to ensure that they have been materialized on the server before serialization. There is a tradeoff here in controlling object-graph size with proxies on the one hand, and transparency of access to persistent classes--regardless of whether the JVM is local or remote--on the other. Removing the need for the client to be OJB-aware could be resolved at either the OJB level or in your application by altering serialization code (writeObject()/readObject() methods I believe) for your persistent classes, to replace any proxies with something else. But in this scenario the client still needs to be concerned with delegating to the server any materialization of associated objects that must be accessed. There has been some discussion from time to time on improving this. Phil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Best practice for using ODMG with EJB? (Cache also)
Thanks for the offer...I can definitely peer around in the code to get a feel for it. However let me ask you this...how would I best use OTM in this situation? Would OTM solve my problem? Let me rephrase, assuming I could use OTM, would the EJB service continue to pass out clones to client applications, and then later on handle the merging, and object deletion etc? Or instead would I be passing out straight objects from the cache, and OTM manages the changes to those objects? Let me ask this different question -- is it a bad assumption on my part if I am going to use the cache to assume the cache will only contain 'committed' data, and not transient data that client applications may or may not be updating to it? If the later is the case, and there is much more to be gained by passing out the original objects from the cache so I can use things like ODMG, I would assume then I need to put into place safeguards to make sure that any changes that my client applications make to those objects are thrown out if not committed within a reasonable time. I know that optimistic locking will handle the scenario when two clients are manipulating the same object at the same time -- but I can't get pass the case in my head where a client application dirties the object, but never saves it -- and now the cache is dirty. I guess in the immediate future, I can code around that by convention since I control all of the client applications, and these client apps live in the same container so they are all pass-by-reference. And when we do allow other outside applications to hit this service it will be in a different container, so now they are pass-by-value, so there is some sanity in that. Our client apps would be using cached objects and would be careful with them. All that leads me to another question that I don't seem to find an answer to: if a remote EJB passes off an OJB dataobject, I would assume you cannot use any proxies because it would not be able to walk back across the wire, correct? I am currently not making use of any proxies because of that assumption. Seems to me that proxies don't fit well at all with EJB's. Have I rambled enough? :) -Andrew -Original Message- From: Brian McCallister [mailto:[EMAIL PROTECTED] Sent: Friday, October 17, 2003 10:18 AM To: OJB Users List Subject: Re: Best practice for using ODMG with EJB? (Cache also) There is no documentation outside of the javadocs for it yet. I can happily provide pointers and samples for you, if you like, from my "learn the OTM" project. I am working on learning my way around it well enough to write decent docs on it -- just a matter of finding the time. I wouldn't call the OTM production-ready yet (which is why I asked about your timeline), and it won't be production-ready in 1.0 so real OTM docs probably won't be published outside of CVS for a while (I could be wrong on this, but in general introducing a whole new API while trying to lock down a 1.0 release is a bad idea). -Brian On Friday, October 17, 2003, at 10:07 AM, Clute, Andrew wrote: > Thanks for the response...you added some interesting point. > > I knew somewhat that the OJB cache only worked with QueryByIdentity(), > but > the gains are still significant for us. Our object model has some > rather > deep and wide trees (for better or worse), and the gain on object > materialization on the hanging objects is a real positive. Maybe I am > overstating it's benefit, but I do see a significant real-world > difference > when the cache is on and off -- however I am not above attributing > that to > bad design on my part for the object model. > > As for OTM -- I will look into that. However, I don't see any > documentation, > or for that matter mention, of it on the OJB site. Am I missing > something? > > -Andrew > > -Original Message----- > From: Brian McCallister [mailto:[EMAIL PROTECTED] > Sent: Friday, October 17, 2003 9:47 AM > To: OJB Users List > Subject: Re: Best practice for using ODMG with EJB? (Cache also) > > > Depending on your deployment timeline you might want to look into the > OTM for this type of deployment. It provides the high-level > functionality you are looking for from ODMG, but it also knows how to > play very nicely with JTA transactions -- a big plus in EJB > containers. The OTM is the least mature of OJB's API's, however. That > said, it is my favorite by a long shot. > > An important note about OJB's cache -- the only query type that > completely reads from the cache as compared to querying is the > QueryByIdentity type query. The cache is primarily used to avoid > object materialization and maintain reference integrity. > > Think for a moment about the query "select products from > org.apache.ojb.tutorials.Product where cost
Re: Best practice for using ODMG with EJB? (Cache also)
There is no documentation outside of the javadocs for it yet. I can
happily provide pointers and samples for you, if you like, from my
"learn the OTM" project. I am working on learning my way around it well
enough to write decent docs on it -- just a matter of finding the time.
I wouldn't call the OTM production-ready yet (which is why I asked
about your timeline), and it won't be production-ready in 1.0 so real
OTM docs probably won't be published outside of CVS for a while (I
could be wrong on this, but in general introducing a whole new API
while trying to lock down a 1.0 release is a bad idea).
-Brian
On Friday, October 17, 2003, at 10:07 AM, Clute, Andrew wrote:
Thanks for the response...you added some interesting point.
I knew somewhat that the OJB cache only worked with QueryByIdentity(),
but
the gains are still significant for us. Our object model has some
rather
deep and wide trees (for better or worse), and the gain on object
materialization on the hanging objects is a real positive. Maybe I am
overstating it's benefit, but I do see a significant real-world
difference
when the cache is on and off -- however I am not above attributing
that to
bad design on my part for the object model.
As for OTM -- I will look into that. However, I don't see any
documentation,
or for that matter mention, of it on the OJB site. Am I missing
something?
-Andrew
-Original Message-
From: Brian McCallister [mailto:[EMAIL PROTECTED]
Sent: Friday, October 17, 2003 9:47 AM
To: OJB Users List
Subject: Re: Best practice for using ODMG with EJB? (Cache also)
Depending on your deployment timeline you might want to look into the
OTM for this type of deployment. It provides the high-level
functionality you are looking for from ODMG, but it also knows how to
play very nicely with JTA transactions -- a big plus in EJB containers.
The OTM is the least mature of OJB's API's, however. That said, it is
my favorite by a long shot.
An important note about OJB's cache -- the only query type that
completely reads from the cache as compared to querying is the
QueryByIdentity type query. The cache is primarily used to avoid object
materialization and maintain reference integrity.
Think for a moment about the query "select products from
org.apache.ojb.tutorials.Product where cost > 10.0". The query has to
be executed as the cache cannot know that it has all the satisfied
objects. Objects in the cache won't be re-materialized at least, but
the query still needs to be run against the database.
It *is* possible to get major caching benefits from OJB, but it needs
to be done above the query execution level. As a great many queries are
against a unique id ( "select product from
org.apache.ojb.tutorials.Product where id=$1" ) you can optimize this a
great deal by providing a hardcoded query against the primary keys on
your query encapsulator that uses an LRUMap to look for a cached
identity and queries on the identity if it finds one. For example:
public class Product
{
public Integer id;
}
public class ProductRepository
{
// from commons-collections
private LRUMap cache;
// this uses a single PK, but you can use multiple pk's with a
multi-map type structure
public Product findById(Integer id)
{
ObjectIdentity oid = cache.get(id);
if (oid != null)
{
// use QueryByIdentity
}
else
{
// use where clause
// add key to this.cache
}
}
}
-Brian
On Friday, October 17, 2003, at 09:24 AM, Clute, Andrew wrote:
I currently have our application running using OJB. I am using the PB
interface because it was the easiest to prototype and get up and
running.
We have a Struts application that calls a collection of EJB services
for
retrieving specific object-trees that the web app needs, along with
Add/Update/Delete methods on the EJB's. One of my main selling points
for
convincing the team to move away from PHP to Java/J2EE was the
strengths of
O/R tools like OJB, specifically the cache -- I think it is a strong
seller,
especially in a 80% read-only application.
So, to facilitate that, I constructed a Façade wrapper around the
PersistenceBroker (so, if I wanted to, I could swap it to ODMG/JDO),
and it seems to work well. I have deployed our 'Core' application as a
collection
of EJB's that make use of OJB under the hood, and then our web
application
as separate war file. But, because they are in the same container
(Jboss),
it makes use of the Local versus Remote interfaces -- which is
desired.
However, when using the cache, and the local interface, any
manipulation
done by the web application on it's objects is manipulating the object
in
cache.
I always though of the cache as a
RE: Best practice for using ODMG with EJB? (Cache also)
Thanks for the response...you added some interesting point.
I knew somewhat that the OJB cache only worked with QueryByIdentity(), but
the gains are still significant for us. Our object model has some rather
deep and wide trees (for better or worse), and the gain on object
materialization on the hanging objects is a real positive. Maybe I am
overstating it's benefit, but I do see a significant real-world difference
when the cache is on and off -- however I am not above attributing that to
bad design on my part for the object model.
As for OTM -- I will look into that. However, I don't see any documentation,
or for that matter mention, of it on the OJB site. Am I missing something?
-Andrew
-Original Message-
From: Brian McCallister [mailto:[EMAIL PROTECTED]
Sent: Friday, October 17, 2003 9:47 AM
To: OJB Users List
Subject: Re: Best practice for using ODMG with EJB? (Cache also)
Depending on your deployment timeline you might want to look into the
OTM for this type of deployment. It provides the high-level
functionality you are looking for from ODMG, but it also knows how to
play very nicely with JTA transactions -- a big plus in EJB containers.
The OTM is the least mature of OJB's API's, however. That said, it is
my favorite by a long shot.
An important note about OJB's cache -- the only query type that
completely reads from the cache as compared to querying is the
QueryByIdentity type query. The cache is primarily used to avoid object
materialization and maintain reference integrity.
Think for a moment about the query "select products from
org.apache.ojb.tutorials.Product where cost > 10.0". The query has to
be executed as the cache cannot know that it has all the satisfied
objects. Objects in the cache won't be re-materialized at least, but
the query still needs to be run against the database.
It *is* possible to get major caching benefits from OJB, but it needs
to be done above the query execution level. As a great many queries are
against a unique id ( "select product from
org.apache.ojb.tutorials.Product where id=$1" ) you can optimize this a
great deal by providing a hardcoded query against the primary keys on
your query encapsulator that uses an LRUMap to look for a cached
identity and queries on the identity if it finds one. For example:
public class Product
{
public Integer id;
}
public class ProductRepository
{
// from commons-collections
private LRUMap cache;
// this uses a single PK, but you can use multiple pk's with a
multi-map type structure
public Product findById(Integer id)
{
ObjectIdentity oid = cache.get(id);
if (oid != null)
{
// use QueryByIdentity
}
else
{
// use where clause
// add key to this.cache
}
}
}
-Brian
On Friday, October 17, 2003, at 09:24 AM, Clute, Andrew wrote:
> I currently have our application running using OJB. I am using the PB
> interface because it was the easiest to prototype and get up and
> running.
>
> We have a Struts application that calls a collection of EJB services
> for
> retrieving specific object-trees that the web app needs, along with
> Add/Update/Delete methods on the EJB's. One of my main selling points
> for
> convincing the team to move away from PHP to Java/J2EE was the
> strengths of
> O/R tools like OJB, specifically the cache -- I think it is a strong
> seller,
> especially in a 80% read-only application.
>
> So, to facilitate that, I constructed a Façade wrapper around the
> PersistenceBroker (so, if I wanted to, I could swap it to ODMG/JDO),
> and it seems to work well. I have deployed our 'Core' application as a
> collection
> of EJB's that make use of OJB under the hood, and then our web
> application
> as separate war file. But, because they are in the same container
> (Jboss),
> it makes use of the Local versus Remote interfaces -- which is desired.
> However, when using the cache, and the local interface, any
> manipulation
> done by the web application on it's objects is manipulating the object
> in
> cache.
>
> I always though of the cache as a 'clean' representation of what was
> in the
> database -- so in all of my retrieve methods in my EJB's, I return
> clone's
> of the DataObjects. This allows for the client applications to
> manipulate
> them, and not affect the cache objects, and send them for committing,
> also
> updating the cache.
>
> But because PB API is not a full persistence API, I am starting to hit
> the
> issues that API's like ODMB fix (deleted objects in collections, object
>
Re: Best practice for using ODMG with EJB? (Cache also)
Depending on your deployment timeline you might want to look into the
OTM for this type of deployment. It provides the high-level
functionality you are looking for from ODMG, but it also knows how to
play very nicely with JTA transactions -- a big plus in EJB containers.
The OTM is the least mature of OJB's API's, however. That said, it is
my favorite by a long shot.
An important note about OJB's cache -- the only query type that
completely reads from the cache as compared to querying is the
QueryByIdentity type query. The cache is primarily used to avoid object
materialization and maintain reference integrity.
Think for a moment about the query "select products from
org.apache.ojb.tutorials.Product where cost > 10.0". The query has to
be executed as the cache cannot know that it has all the satisfied
objects. Objects in the cache won't be re-materialized at least, but
the query still needs to be run against the database.
It *is* possible to get major caching benefits from OJB, but it needs
to be done above the query execution level. As a great many queries are
against a unique id ( "select product from
org.apache.ojb.tutorials.Product where id=$1" ) you can optimize this a
great deal by providing a hardcoded query against the primary keys on
your query encapsulator that uses an LRUMap to look for a cached
identity and queries on the identity if it finds one. For example:
public class Product
{
public Integer id;
}
public class ProductRepository
{
// from commons-collections
private LRUMap cache;
// this uses a single PK, but you can use multiple pk's with a
multi-map type structure
public Product findById(Integer id)
{
ObjectIdentity oid = cache.get(id);
if (oid != null)
{
// use QueryByIdentity
}
else
{
// use where clause
// add key to this.cache
}
}
}
-Brian
On Friday, October 17, 2003, at 09:24 AM, Clute, Andrew wrote:
I currently have our application running using OJB. I am using the PB
interface because it was the easiest to prototype and get up and
running.
We have a Struts application that calls a collection of EJB services
for
retrieving specific object-trees that the web app needs, along with
Add/Update/Delete methods on the EJB's. One of my main selling points
for
convincing the team to move away from PHP to Java/J2EE was the
strengths of
O/R tools like OJB, specifically the cache -- I think it is a strong
seller,
especially in a 80% read-only application.
So, to facilitate that, I constructed a Façade wrapper around the
PersistenceBroker (so, if I wanted to, I could swap it to ODMG/JDO),
and it
seems to work well. I have deployed our 'Core' application as a
collection
of EJB's that make use of OJB under the hood, and then our web
application
as separate war file. But, because they are in the same container
(Jboss),
it makes use of the Local versus Remote interfaces -- which is desired.
However, when using the cache, and the local interface, any
manipulation
done by the web application on it's objects is manipulating the object
in
cache.
I always though of the cache as a 'clean' representation of what was
in the
database -- so in all of my retrieve methods in my EJB's, I return
clone's
of the DataObjects. This allows for the client applications to
manipulate
them, and not affect the cache objects, and send them for committing,
also
updating the cache.
But because PB API is not a full persistence API, I am starting to hit
the
issues that API's like ODMB fix (deleted objects in collections, object
locking, etc) -- and want to get a feel for how best to use something
like
ODMG in my situation.
My goals are:
1) To have a centralized application that handles all database and
service
level transactions. It would hand out objects from the cache
(preferably
clones) and receive objects to store them. We only have one client
application that would be using this, but down the road we will have
many
more
2) Move to an ODMG like API that can manage locking and whatnot to
free up
not having to manage object locking, deletion, etc
3) For Goal 1 to make use of the cache -- most of our applications are
read-only. So that makes sense to make heavy use of the cache -- but
at the
same time we do have update scenarios that I would like to be 'atomic'.
Is there a pattern that facilitates these goals?
Thanks!
-Andrew
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
