In article <1158664862.410864.211130@i42g2000cwa.googlegroups .com>,
frank.van.bortel@gmail.com says...
>
>
> > Hi Frank, where do I find your blog?
> >
>
> Really!
> http://www.google.com/search?client=...=Google+zoeken
>
>
OK I could've googled but I thought you'd have appreciated the
opportunity for a little self-promotion

--

jeremy

On Tue, 19 Sep 2006, jeremy0505@gmail.com wrote:
> In article <ulkog4a9w.fsf@rcn.com>, Galen Boyer says...
>> On Mon, 18 Sep 2006, jeremy0505@gmail.com wrote:
>> > In article <uejua5rr0.fsf@rcn.com>, Galen Boyer says...
>> >
>> >> Why do you need to worry about redo?
>> >>
>> >>
>> > Perhaps I don't - see other responses.
>>
>> I would look at materialized views myself, because, that is really
>> what you are describing (ie, I want to have a query not have to
>> execute everytime, but instead, have it stored so I can get the
>> results quicker) An MV helps solve that in a most impressive fashion.
>>
> This may help actually, yes - however when the user requests the data
> to be refreshed, it needs to be up-to-date rather than based on the
> latest snapshot (am I right that MVs are periodically refreshed rather
> than instantaneously with each transaction that may affect the
> content?).


Well, if you are worried about that, you certainly shouldn't be trying
to save your own manufactured snapshot. You will never get that correct
while Oracle will always get that correct.


>> But, If you really needed to use a global temp to get away from the
>> redo, then you could do something like the following pseudo-code:
>>
>> IF (p_clientpackage.count_global(client_id) < 1)
>> BEGIN
>> p_clientpackage.insert_global;
>> END
>>
>> p_clientpackage.get_from_global;
>>
>>
>> This would mean you execute the operation for each client, at most,
>> the number of connections you have in the pool. It would also need
>> some boundary questions asked, like, what if the query could return 0
>> rows...
>
> No problem, thanks for the pointer.
>
>>
>> Of course, your global temp would need to be "ON COMMIT PRESERVE
>> ROWS".
>>
>>
> As I understand it, this allows the rows to be preserved across
> transactions NOT across sessions - and as mentioned, a new session is
> necessarily created for each user-interaction (apache/mod_plsql).

The comments were assuming that the apache/mod_plsql has a connection
pool. Then, a new session wouldn't mean a _new_ connection. Just one
retrieved from the pool.

--
Galen Boyer

In article <uac4v4aks.fsf@rcn.com>, Galen Boyer says...
> On Tue, 19 Sep 2006, jeremy0505@gmail.com wrote:
> > In article <ulkog4a9w.fsf@rcn.com>, Galen Boyer says...
> >> On Mon, 18 Sep 2006, jeremy0505@gmail.com wrote:
> >> > In article <uejua5rr0.fsf@rcn.com>, Galen Boyer says...
> >> >
> >> >> Why do you need to worry about redo?
> >> >>
> >> >>
> >> > Perhaps I don't - see other responses.
> >>
> >> I would look at materialized views myself, because, that is really
> >> what you are describing (ie, I want to have a query not have to
> >> execute everytime, but instead, have it stored so I can get the
> >> results quicker) An MV helps solve that in a most impressive fashion.
> >>
> > This may help actually, yes - however when the user requests the data
> > to be refreshed, it needs to be up-to-date rather than based on the
> > latest snapshot (am I right that MVs are periodically refreshed rather
> > than instantaneously with each transaction that may affect the
> > content?).
>
>
> Well, if you are worried about that, you certainly shouldn't be trying
> to save your own manufactured snapshot. You will never get that correct
> while Oracle will always get that correct.
>
It isn't a "own manufactured snapshot" - merely the results of a query
such as "show me the orders in the last 24 hours" which we then are
allowing the user to view in the way he chooses via the web interface.
Every time the query runs, it will be on the current at the time data.

--

jeremy

On Wed, 20 Sep 2006, jeremy0505@gmail.com wrote:
> In article <uac4v4aks.fsf@rcn.com>, Galen Boyer says...
>> On Tue, 19 Sep 2006, jeremy0505@gmail.com wrote:
>> > In article <ulkog4a9w.fsf@rcn.com>, Galen Boyer says...
>> >> On Mon, 18 Sep 2006, jeremy0505@gmail.com wrote:
>> >> > In article <uejua5rr0.fsf@rcn.com>, Galen Boyer says...
>> >> >
>> >> >> Why do you need to worry about redo?
>> >> >>
>> >> >>
>> >> > Perhaps I don't - see other responses.
>> >>
>> >> I would look at materialized views myself, because, that is really
>> >> what you are describing (ie, I want to have a query not have to
>> >> execute everytime, but instead, have it stored so I can get the
>> >> results quicker) An MV helps solve that in a most impressive
>> >> fashion.
>> >>
>> > This may help actually, yes - however when the user requests the
>> > data to be refreshed, it needs to be up-to-date rather than based
>> > on the latest snapshot (am I right that MVs are periodically
>> > refreshed rather than instantaneously with each transaction that
>> > may affect the content?).
>>
>>
>> Well, if you are worried about that, you certainly shouldn't be
>> trying to save your own manufactured snapshot. You will never get
>> that correct while Oracle will always get that correct.
>>
> It isn't a "own manufactured snapshot" - merely the results of a query
> such as "show me the orders in the last 24 hours" which we then are
> allowing the user to view in the way he chooses via the web interface.
> Every time the query runs, it will be on the current at the time data.

But, then, when the user subsequently looks at the data, it is not in
real-time. It, instead, is at some time after the "snapshot" was
taken. How come they are okay with the subsequent reads of the data,
but are not okay with the data maybe, already, being a little behind
exact committed transactions at the time of the initial query?

--
Galen Boyer

In article <u3bal4umo.fsf@rcn.com>, Galen Boyer says...
>
> But, then, when the user subsequently looks at the data, it is not in
> real-time. It, instead, is at some time after the "snapshot" was
> taken. How come they are okay with the subsequent reads of the data,
> but are not okay with the data maybe, already, being a little behind
> exact committed transactions at the time of the initial query?
>
>
Well the first time the user clicks to see the data, it will run the
query and present the results. For sure, when he changes the sort order
by clicking a column heading, this is going to read the data from the
"cache" table. As long as the user knows that the data was 100% up-to-
date at the time of the intial query, that is entirely adequate.

--

jeremy