From: Guillermo.Acilu@...
Date: 2008-07-16T18:56:00+09:00
Subject: Re: Handling exceptions in Threads

--=_alternative 0036FC8AC1257488_=
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable

Hello,

I have solved the problem. It was something like this:

def mymethod
        row =3D myselect.execute(select)
        if row.next
                Thread.new {mymethod(row.getcursorvalue)}
        end
Rescue
        puts error
end

As you can see the the variable "row" is local to the method, but when I=20
was including it inside of the thread block, it becomes local of the=20
thread. The database was answering with an error like this "No cursor=20
opened", since the cursor is not valid in the thread context. The Rescue=20
clause was not responding, since the error was introduced before the=20
method was actually called.

> you could handle the results in threads too using the same pattern.=20
> the key is here is simply to eliminate the MT aspect of the db handle=20
> usage - for sanity and correctness.

I am using JRuby 1.1.2 with the Oracle JDBC. The engine is an Oracle 11i=20
running on a separated server, but sometimes I use it in my own MacBook=20
PRO on a linux vmware virtual machine. Do you think it is not thread safe? =

also, why do you think that it is not good to run the queries in parallel?

Cheers,


---
Guillermo Acilu
Senior Engineer, Koiaka GmbH

Koiaka GmbH
Riesserkopfstr. 17=20
82467 Garmisch-Partenkirchen
Tel: +49 (0)8821 9679555=20
Fax: +49 (0)8821 730 9185=20
Mailto:guillermo.acilu@koiaka.com
http://www.koiaka.com

Amtsgericht M=FCnchen: HR B 161 041=20
Gesch=E4ftsf=FChrer: Guillermo Acilu=20
Sitz: Garmisch-Partenkirchen

Diese Email kann vertrauliche und/oder rechtlich gesch=FCtzte Informationen=
=20
enthalten. Wenn Sie nicht der richtige Adressat sind oder diese Email=20
irrt=FCmlich erhalten haben, d=FCrfen Sie diese weder benutzen, kopieren,=20
weiterleiten oder irgend eine Ma=DFnahme einleiten, die im Zusammenhang mit=
=20
dem Inhalt dieser Email steht. Informieren Sie bitte sofort den Absender=20
und vernichten Sie die irrt=FCmlich erhaltene Email vollst=E4ndig.
Vielen Dank!

This e-mail message may contain confidential and/or privileged=20
information. If you are not an addressee or otherwise authorized to=20
receive this message, you should not use, copy, disclose or take any=20
action based on this e-mail or any information contained in the message.=20
If you have received this material in error, please advise the sender=20
immediately by reply e-mail and delete this message completely.
Thank you!





From:
"ara.t.howard" <ara.t.howard@gmail.com>
To:
ruby-talk@ruby-lang.org (ruby-talk ML)
Date:
15.07.2008 18:24
Subject:
Re: Handling exceptions in Threads




On Jul 15, 2008, at 6:35 AM, Guillermo.Acilu@koiaka.com wrote:

>
> If I leave the Thread.abort=5Fon=5Fexception =3D false, the algorithm end=
s=20
> after
> triggering about 10 threads. If I set it to=20
> Thread.abort=5Fon=5Fexception =3D
> true, the algorithm end abnormally, but without printing any error
> message.
>
> I have added the following code at the end of the method called by the
> thread:
>
> rescue Exception =3D> error
>    puts "#{error.class}: #{error.message}"
>
> But I cannot get any error message in the console. I am sure that the
> problem is something related with the database, but I do not know=20
> how to
> solve the problem if I do not see the error message.
>
> Any ideas?


1) STDERR.puts message

stdout bufferes and can get lost


2) it's *highly* unlikely the db handle is thread safe and, if it is,=20
it'll be native thread safe not green thread safe.  aka - you will not=20
get anything from using MT to execute your queries.


so, just use producer/consumer to both simplify and speed up your=20
application.  for example


q =3D Queue.new

queries =3D list=5Fof=5Fqueries

done =3D Object.new.freeze

producer =3D Thread.new do
   Thread.current.abort=5Fon=5Fexception

   queries.each do |query|
     q.push db.execute(query)
   end

   q.push done
end

while( ( result =3D q.pop) !=3D done )
   handle=5Fresult result
end


you could handle the results in threads too using the same pattern.=20
the key is here is simply to eliminate the MT aspect of the db handle=20
usage - for sanity and correctness.

cheers.

a @ http://codeforpeople.com/
--
we can deny everything, except that we have the possibility of being=20
better. simply reflect on that.
h.h. the 14th dalai lama






--=_alternative 0036FC8AC1257488_=--