db-torque-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ben Bookey" <ben.boo...@gistec-online.de>
Subject AW: AW: Village for Oracle patch.
Date Thu, 04 Nov 2004 10:21:25 GMT
Hi Sarav,

I forgot to mention that there is also alot of system.outs done in the
patched village. i.e. done it using Is this expected? It would be great
to switch this off somehow. This example below is out'd when i perform the
save() method on the blob table. Can I switch off somehow with the binaries?
or do i need to get the source files myself.

'===========================================================================
==================
LOB Query: SELECT BGFILE FROM main WHERE ID_MAIN = ? AND ID_USER = ? AND
RESTITLE = ? AND RESALTTITLE is NULL AND REFDATE = ? AND REFDATETYPE = ? AND
IDABS = ? AND IDSTATUS = ? AND BGFILENAME = ? AND REFSYSID is NULL AND
REFSYSNAME is NULL AND PROJECTION = ? AND ZONE = ? AND ELLIPSOID is NULL AND
SEMIMAJAXIS = ? AND AXISUNITS = ? AND DENFLATRAT = ? AND DATUM is NULL AND
INCWITHDATASET = ? AND RESFEES is NULL AND ORDINSTR is NULL AND ORDTURN is
NULL AND MDFILEID = ? AND MDFILEIDMINUSURLDOMAIN = ? AND MDPARENTID = ? AND
MDDATEST = ? AND MDSTANNAME = ? AND MDSTANVER = ? AND MDLANG = ? AND MDCHAR
= ? AND MDHRLV = ? AND MDHRLVNAME = ? AND USELIMIT = ? AND MDDATESTTYPE = ?
FOR UPDATE
Setting ID_MAIN = 217
Setting ID_USER = 1
Setting RESTITLE = Höhenfolie der Deutschen Grundkarte 1:5000
Setting REFDATE = 1962-01-01 00:00:00.0
Setting REFDATETYPE = 1
Setting IDABS = Die Deutsche Grundkarte 1:5000 ist ein amtliches
topographisches Kartenwerk. Als Ergebnis einer umfassenden Landesaufnahme
stellt sie die Erdoberfläche ohne maßstabsbedingte Generalisierung mit allen
wesentlichen Einzelheiten geometrisch exakt dar. Die Höhenfolie stellt eine
Ergänzung zur Grundrißtopographie dar und kann bei Bedarf in das Kartenbild
eingeblendet werdens.
Setting IDSTATUS = 1
Setting BGFILENAME = Hoehen.jpg
Setting PROJECTION = 0
Setting ZONE = 0
Setting SEMIMAJAXIS = 0.0
Setting AXISUNITS = 9
Setting DENFLATRAT = 0.0
Setting INCWITHDATASET = 1
Setting MDFILEID = www.bochum.de\metadaten\DGK5_Höhe4
Setting MDFILEIDMINUSURLDOMAIN = DGK5_Höhe4
Setting MDPARENTID = www.bochum.de\metadaten\DGK5
Setting MDDATEST = Thu Nov 04 11:12:07 CET 2004
Setting MDSTANNAME = InGeo Meta Data Format MDF
Setting MDSTANVER = 2.2
Setting MDLANG = 25
Setting MDCHAR = 4
Setting MDHRLV = 9
Setting MDHRLVNAME = feature
Setting USELIMIT = Einfaches Nutzungsrecht zur internen Nutzung. Weitere
Nutzungen müssen in gesonderten Nutzungsvereinbarungen geregelt werden.
Setting MDDATESTTYPE = 3

'===========================================================================
==================


regards
Ben

-----Ursprüngliche Nachricht-----
Von: Saravana Krishnan [mailto:saravkrish@uky.edu]
Gesendet: Mittwoch, 3. November 2004 23:31
An: Apache Torque Users List
Betreff: Re: AW: Village for Oracle patch.


Hi Tino,

  I personally consider these two scenarios to be different, because if
I remember right, in your case the locking was done by some other code
outside your control and it was not a part of Torque. Your code ended up
waiting on the locked record.

In this case, the locking code and the waiting code are a part of
Torque, or rather village.

Ben,

  My suggestion for a temporary fix would be, getting the village source
from me and adding a NO WAIT at the end of all the LOB related SQL
queries. It shouldn't be difficult (you can find the code of interest
under a method like LOBQueryString or something). The proper way to take
care of this would be to look at the options passed to Village be Torque
and then add NO WAIT if Torque doesn't want locking. But I'm not sure if
Torque has such a property and if it does, I'm not sure if it passes it
to Village

Thanks,
Sarav

On Tue, 2004-11-02 at 06:10, Sperlich, Tino wrote:
> Hi,
>
> I have faced a similar problem lately
> and I think that issue is a general torque one
> rather than only blob-related.
> With the help of
> Arne Siegel I've solved it for my part.
> See Arne's comments here:
> <http://www.mail-archive.com/torque-user@db.apache.org/msg03288.html>
>
> HTH, regards,
>
> Tino
>
> -----Ursprüngliche Nachricht-----
> Von: Ben Bookey [mailto:ben.bookey@gistec-online.de]
> Gesendet: Dienstag, 2. November 2004 09:55
> An: Apache Torque Users List
> Cc: saravkrish@uky.edu
> Betreff: AW: Village for Oracle patch.
>
>
>
>
> Hi Saravana,
>
>
> > >>Is this hanging noticed only in tables with LOBs or does it hang on
any
> > >>table where locking is performed?
> >
> > This is a very good question :-) I think that this table with the LOB is
> the
> > only one where any locking is taking place in my application. My
> > understanding is that Oracle locking is only done when a specific
"select
> *
> > where * for update" command is used (this command is also system.out'd,
> > presumably from your patch). If this is the case, then its the only
table
> > where I have noticed this problem, as the remainder of the app is doing
> > standard Torque Deletes, Updates and Inserts using Torque (varchar and
> > numbers) and I believe from the Torque logs that no such commands are
> done.
>
> ==So I assume you access your tables using only Torque and don't use any
> ==custom SQL statements to access the database.
> Correct.
>
> > One futher point I would like to add, is that this problem is not likely
> to
> > happen alot in my app. I have locked the row
> > using SQLplus, and not another instance of myApp.
>
> ==What do you mean by "locked the row using SQLplus"? Do you mean Stored
> ==procedures? Why do you lock the row in the first place? I'm confused.
> ==Explain more about the scenario please. What is myApp (I can see its
> ==something you wrote ;-) ) Is your application a webapp or a standalone
> ==app?
>
> MyApp is a tomcat, servlet database app with jsp. Upto max 20 users
> accessing the same
> oracle instance and tablespace using this app. After sleeping on it:-) the
> only place
> where locking must take place is with the BLOB. This is due to the writing
> of the filesize normally
> associated with blobs (we limit this to 30k but this can be increased if
the
> customer so wishes).
>
> In this environment users *could* get conflicts, when attempting a blob
> update simultanesously on
> the same row. I reproduce a locking scenario by using the
> %ORACLE_HOME%\ora92\bin\SQLplus.exe, and selecting for update a particular
> row containing a LOB for update. I then attempt a blob update with myAPP
and
> it hangs until
> I COMMIT on SQLplus.exe. This is in affect reproducing a slow update of
the
> blob to the database.
>
> We are a group of three developers.
>
> ==I think there is a way to ask Oracle to not wait (add NO WAIT at the
> ==end) but I'm not sure I want to make it the default option of Village. I
> ==don't know if Torque passes on "lock requirements" to Village. If it
> ==does and I can figure out how to get that property within village, I can
> ==add the feature to not wait on locks.
>
> Thats what I was thinking. Adding NO WAIT, and returning an Exception,
would
> remove this problem( issue would be better perhaps:-)) completely.  I
guess
> I have not really thought about the "real chances" of user-conflicts
> occuring in myAPP. I suppose the chances are minimal, and because the
> filesize is also minimal a second user shouldnt have to wait so long until
> lock is released. More conflicts would occur when the filesizes are
bigger.
>
> Await your comment :-)
>
> Ben
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: torque-user-unsubscribe@db.apache.org
> For additional commands, e-mail: torque-user-help@db.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: torque-user-unsubscribe@db.apache.org
> For additional commands, e-mail: torque-user-help@db.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: torque-user-unsubscribe@db.apache.org
> For additional commands, e-mail: torque-user-help@db.apache.org
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: torque-user-unsubscribe@db.apache.org
For additional commands, e-mail: torque-user-help@db.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: torque-user-unsubscribe@db.apache.org
For additional commands, e-mail: torque-user-help@db.apache.org


Mime
View raw message