Hello João Paulo
Stored procedures aren't there to be used from DODS at run-time. We had
in mind completely different usage, so you're safe if you skip them
completely.
Idea for these stored procedures came from necessity. Although it
doesn't happen to often, we sometimes have to _manually_ insert some
rows into database. In SQL console you cannot access Java implementation
of ObjectIdAllocator :-) hence stored procedures allocate 1 OId, they
also do it in way compatible with Java implementation...
In document "Using DODS" you'll find section "Stored procedures used as
an oid allocator" that clarifies things.
hth
you wrote:
Hi.
Just to clarify my opinion. I now that stored procedure is faster than
the application doing two queries: one select for getting the value and
one update to update the value.
But normally this code is executed vary rarely and the performance
benefits will be very small at the cost of a more complicated approach.
In the other hand, the actual stored procedure (DODS 7.04) have no
benefit performance because they only allocate 1 oid by execution.
In the dods framework, every time a new DO object is created an oid is
allocated. The new object don't ever need to be saved to spent the oid.
It only need to be created.
I think that if this stored procedure approach is the way, the stored
procedures will have to allocate a range of oid using an increment
passed as parameter or we are going to have big bottleneck in our
applications.
I hope i made myself more clear this time :).
Best regards.
Jo�o Paulo Ribeiro
Jo�o Paulo Ribeiro wrote:
Hello.
We are using DODS 7.04 at work. I have generated the data layer for an
oracle database and found two functions: create_oid and
create_oid_per_table.
Later I found that the two functions were not used in the Java class
generated by dods.
It's ok to me because i think that this approach complicate something
already simple and working.
If the allocation oid code go into the database as stored procedures,
this will force dods to have similar stored procedures for every
database or it will have to detect which database it is working with and
behave accordingly.
As i said, i think this will only complicate with no really benefit
because the store procedure should be faster but this application code
code should be executed very very rarely. If not the data base
configuration of your application need to be tuned (see
ObjectId/CacheSize).
But may be I'm not seeing the big picture and the stored procedure have
really a big benefit in this particular case.
Assuming that I'm not aware of the benefits and the dods teams think
that this is the way, i just want call your attention for the fact that
the stored procedure is only allocating 1 objectid per invocation and
this a bottleneck performance for the database inserts: the stored
procedure will have to be executed for every insert to get the objectid.
If this stored procedures will be used in the future, i think they
should receive the increment as a parameter to allow the application to
control how much oids it want to allocate and to remove the allocation
bottleneck from database/application. For example, with an increment of
10000, instead of executing the stored procedure for every insert it
will be executed only 1 time for every 10000 inserts. This is really a
small change to the stored procedures.
Can someone of the development team clarify this situation?
Best regards.
Jo�o Paulo Ribeiro
regards
--
Vlada
"Any fool can steer a ship, sir. It's just knowing where to take it."
--
You receive this message as a subscriber of the enhydra@xxxxxxxxxxxxx mailing
list.
To unsubscribe:
mailto:enhydra-unsubscribe@xxxxxxxxxxxxx
For general help:
mailto:sympa@xxxxxxxxxxxxx?subject=help
ObjectWeb mailing lists service home page:
http://www.objectweb.org/wws
| 