db-ojb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Lance Eason" <lance.ea...@whisperwire.com>
Subject RE: Oracle 9i BLOB malfunction / 4k mystery (issue OJB170)
Date Fri, 16 May 2003 05:26:41 GMT
As I understand the state of the world it's hard to fit a fix for this into OJB's current model
because at the FieldConversion level there's no access to the primary key info.  But Oracle's
workaround involves doing a select for update on the row therefore you need primary key info.
 Getting primary key info down to the FieldConversion level involves some distasteful mucking
with some number of interfaces all to work around a bug that's Oracle's fault in the first
place.

Backing up a few levels though, all updates ultimately originate from PersistenceBroker.store().
 PersistenceBroker implementations are replaceable through OJB properties.  What I'm imagining
is a PersistenceBrokerToPatchOraclesBloodyStupidBlobProblemImpl that basically delegates to
a normal PersistenceBroker to store all the non-BLOB/CLOB columns and handles those itself
specially.  I am admittedly fuzzy on how it would accomplish delegating only a subset of the
columns (I'm imagining something involving custom attributes on <field-descriptor> mappings
or some such) and there may be other interception points that make more sense, but somewhere
there should be some interception point between PersistenceBroker.store() and the FieldConversion
level that has enough context (i.e. access to primary key info) to do the right thing.

Alternatively I personally could live with having to make two calls to workaround this problem:

   broker.store(myObject);
   OracleBLOBPatch.storeBlobs(broker, myObject, ...whatever else it needs...);

As you say though this starts to break encapsulation and not knowing anything about the ODMG
side of OJB I don't know if it causes havoc there.

-----Original Message-----
From: Torsten Schlabach [mailto:tschlabach@gmx.net]
Sent: Thursday, May 15, 2003 11:28 PM
To: 'OJB Developers List'
Subject: AW: Oracle 9i BLOB malfunction / 4k mystery (issue OJB170)


>> OJB let's you access the JDBC layer so you can work around it
yourself

Can you tell in short words how that would look like? I am not yet sure.
Also, won't that totally break the idea of encapsulation or layering in
the application. It might be a way of getting this to work *now*, but no
really a solution.

-----Urspr├╝ngliche Nachricht-----
Von: Lance Eason [mailto:lance.eason@whisperwire.com] 
Gesendet: Donnerstag, 15. Mai 2003 23:18
An: OJB Developers List; thma@apache.org
Betreff: RE: Oracle 9i BLOB malfunction / 4k mystery (issue OJB170)

Yeah, you're right.  I realized after I wrote the note that OJB let's
you access the JDBC layer so you can work around it yourself.  As one of
the people burned by this problem I'd actually be perfectly happy if
core OJB wasn't modified but the problem was clearly documented and
sample workaround code was provided and ideally some patch utility class
was provided to do the repetitive work of doing the SELECT FOR UPDATE
and writing out the contents.

-----Original Message-----
From: Thomas Mahler [mailto:thma32@web.de]
Sent: Thursday, May 15, 2003 2:15 PM
To: OJB Developers List
Subject: Re: Oracle 9i BLOB malfunction / 4k mystery (issue OJB170)


Hi angain

Lance Eason wrote:
> I'll answer the first question.  It is most definitely an Oracle bug.
> Regardless it is important that OJB address it in my opinion.  

+1

> Users
> using JDBC directly can work around this bug, users using OJB
> currently cannot.  

As it's pretty OK to use OJB to obtain JDBC connections you can use OJB 
*and* use direct JDBC calls to work around this problem.

> That creates a decision point when BLOB/CLOB data
> is required of use Oracle or use OJB and to most people the DBMS is
> going to be the higher priority.

don't agree, see above.

> 
> And yes the OCI driver does not exhibit this bug but it is not always
> possible to use the OCI driver.  First it requires an Oracle client
> installation on each machine and second it is native code and at
> least for Oracle 8.1.7 is flaky (many, many SEGFAULTs in our recent
> load testing).

As I mentioned in my other mail, Oracle seems to have fixed the 
CLOB/BLOB problems with the thin driver in their latest release!

I think we should further investigate this before launching bug fix 
rampage. ;-)

cheers,
thomas

> 
> -----Original Message----- From: Torsten Schlabach
> [mailto:TSchlabach@gmx.net] Sent: Thursday, May 15, 2003 6:29 AM To:
> ojb-dev@db.apache.org Subject: Re: Oracle 9i BLOB malfunction / 4k
> mystery (issue OJB170)
> 
> 
> Folks,
> 
> if I get this right, we still don't have a *real* solution to this,
> do we? I found that Per-Olof's CLOB patch for using the thin driver
> made it to the CVS, but I understand it only fixes this for text < 4
> KB, right?
> 
> So first of all I thought it was a good idea to enter an issue in the
> bug database at http://scarab.werken.com/scarab/issues/id/OJB170
> (which became OJB170).
> 
> So to me there are at two questions right now:
> 
> 1. Is this an OJB bug, an Oracle bug or both? 2. How do we *want* do
> handle this at all?
> 
> What I mean is: To what column type would I map a String object that
> I except to grow very large (i.e. some dozends KB of text)?
> 
> I might map it to JDBC type CLOB which would be closest to reality
> but this will break with a class cast exception (you cannot cast a
> string to a java.sql.Clob).
> 
> If you map it to anything else such as LONGVARCHAR Oracle will not
> care but this will probably break other things.
> 
> In fact it might depend on your application what you want back in
> your bean when using a CLOB column: You either might want to get a
> stream you can read from in some other place or you might want to
> just get the stuff into a String and not care about it any more
> (which would make your application code much less Oracle specific by
> the way).
> 
> This is essentially two different JDBC types needed for the same type
> of DB column. Does the framework support this at all? I am wrong in
> any assumption?
> 
> Torsten
> 
> P.S.: I would like to post this as a comment in Scarab, but I did not
> yet find out how to edit the issue. I was able to submit it though.
> Any help appreciated.
> 
> Original Message: ----------------- From: Thomas Poeschmann
> t.poeschmann@exxcellent.de Date: Mon, 12 May 2003 16:05:08 +0200 To:
> ojb-dev@db.apache.org Subject: Re: Oracle 9i BLOB malfunction / 4k
> mystery
> 
> 
> Hi there,
> 
> 
>> Michael Mogley wrote: Thomas Poeschmann says on the list that he
>> almost has a solution, using the above method I presume.
> 
> 
> Yes, of course using the SELECT FOR UPDATE. Sorry for promising
> posting code but not doing it, but I will try to find it this
> evening. It is probably just for reference for you, since you already
> have it.
> 
> 
>> Are there other dbmses and drivers that exhibit the same irregular
>>  behavior regarding LOB┬┤s.
> 
> 
> Not that I know. Sometimes it is different to call one of the methods
> on a statement to bring certain Java objects in. For example passing
> an array in as a String. But I have never seen anything hard as
> Oracle XLOBs ;)
> 
> 
>> Unfortunatly, our solution (apart from the the fix submitted)
>> currently consists of changing to the oci driver. Sad but true.
> 
> 
> Which has other drawbacks, but well... Other ORM can not handle it
> either with thin, by the way ;)
> 
> Kind regards,
> 
> Thomas
> 
> 
> ---------------------------------------------------------------------
>  To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org For
> additional commands, e-mail: ojb-dev-help@db.apache.org
> 
> 
> 
> ---------------------------------------------------------------------
>  To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org For
> additional commands, e-mail: ojb-dev-help@db.apache.org
> 
> 
> ---------------------------------------------------------------------
>  To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org For
> additional commands, e-mail: ojb-dev-help@db.apache.org
> 
> 


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


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


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


Mime
View raw message