AEH wrote:
> The goal for using a materialized view is provide a smaller group of
> data for the search to run against so that it doesn't have to do all of
> the ugly joins within the search itself.
>
> Because this is a user facing search it needs to be as quick as
> possible so creating a subset of records to join against is useful.
>
> If the session had been persistant I would have loaded all the data for
> that user into a Global temp table when they logged in and then
> updated that table as they created transactions in the system, and then
> joined the search criteria against that. However the session isn't
> persistant so a Global Temp isn't an option. So I'm left with something
> that works but I don't like or a MV which I haven't worked with before.
>
>
>>And as readers don't block writers, writers don't block readers, and
>>readers most certainly do not block readers, you can query anything
>>you like. Unless you meant something different, of course.
>
>
> Hmmm. I guess I'm cautious about what happens if 2 different
> procedures, try to insert into the MV at the same time. Will one throw
> an error? Will one or both of them succeed etc?
>
> Does that sucessfully clarify things?
> Thanks for your time.
> A.E. Harris
>
I see you did mean something else
yes - two calls to DBMS_REFRESH.REFRESH would be
a (performance) problem. If you even managed to
do the at the same time, one would block the other,
causing a delay.

Non-persistent connections, searches... sounds like
a web application with a search screen.
If so, I'd urge you to look into InterMedia Text.

--
Regards,
Frank van Bortel