Re: opening multiple databases from same program

[email protected] Sun, 03 Oct 2010 12:49:21 +1000
Newsgroups gmane.comp.java.orm.simpleorm
Message-ID <[email protected]>
Hello Noel,

No need to fork the code, the hooks you need are already there, although you might like to wrap them. (attach/detachFromThread).

If you do end up using multiple threads, then query into a DataSet, detach the data set, and send it to the UI thread.  In that way your threading will always be clean.  But I agree, avoid threads.

Anthony

At 08:08 PM 23/09/2010, Noel Grandin wrote:
>  
>
>
>That sounds like a good idea, and I tried in my last project. Turns out it's much harder than it seems.
>Firstly, you need lots of extra boilerplate code. But I can live with that.
>
>More importantly, I have to be very very careful about disabling relevant pieces of the UI so I don't end up having 2 background queries stomping on each other.
>It is really really easy to have the user click on 2 things in succession, the 2 queries both execute in the background, and then my applications state becomes horribly messed up.
>
>Basically, it's more pain than it's worth, especially since 99.9% of the time my queries execute fast enough that I don't need to execute them in the background.
>
>And I believe that libraries like SimpleORM should strive to make my life easier, not harder. 
>Especially when all I asking for is a way to disable some checking.
>
>After all, I am the programmer, should I not be in control of the situation, rather than having the library force me into one way of doing things?
>
>-- Noel.
>
>Thomas Leichner wrote: 
>>
>>You can have a Swing desktop application and work with many threads. You can 
>>send the Swing event thread a command with the  EventQueue.invokeLater 
>>function. You can also send a command from the Swing event thread to your own 
>>threads, implementing the same mechanism, which is used by the EventQueue 
>>class. This will be much easier than changing the SimpleORM source code. And 
>>it is much more flexible. For example, your swing application is still able to 
>>react, when a long drawn database sql-statement is executed. In the Java 
>>standard library you can find everything you need to implement such a solution.
>>
>>
>>Thomas
>>
>>
>>
>>Am Dienstag, 21. September 2010, um 14:33:29 schrieben Sie:
>>>
>>>I'm effectively running several smaller apps inside the same Java VM.
>>>Each app has it's own database.
>>>Since this is a Swing desktop application, most of the action happens on
>>>the Swing event dispatch thread. This means that I end up talking to
>>>multiple databases from the same thread, triggering the check.
>>>
>>>Sigh. I keep having this problem.
>>>Everybody is developing web-applications these days, which means that all
>>>of the ORM frameworks are designed around the HTTP request-response cycle.
>>>I ended up dumping Hibernate because it won't play nice with desktop
>>>applications.
>>>
>>>Luckily SimpleORM is relatively straight-forward code, so I'm probably just
>>>going to run my own private branch of it, since my changes don't seem to
>>>meet with popular approval.
>>>
>>>-- Noel
>>>
>>><mailto:[email protected]>[email protected] wrote:
>>>>
>>>>It is actually possible to dissassociate sessions from threads, and thus
>>>>have several. But that is a very odd thing to want to do. What are you
>>>>trying to achieve?
>>>>
>>>>(Ususally trying to open a session on a thread that already has an open
>>>>session means that you did not close the previous session, leading to a
>>>>connection leak, which is why SimpleOrm fails fast.)
>>>>
>>>>Anthony
>>>>
>>>>At 02:02 AM 10/07/2010, you wrote:
>>>>>
>>>>>Hi,
>>>>>
>>>>>well, AFAIK, you can't do that... !
>>>>>
>>>>>SSessionJdbc has built-in checks that a connection is single threaded
>>>>>using a ThreadLocal object. [I think Hibernate has some kind of best
>>>>>practice to achieve the same goal (I'm not formal here, I didn't use
>>>>>hibernate for years)]
>>>>>
>>>>>There is only one dataSource per SSessionJdbc and one SSessionJdbc per
>>>>>thread.
>>>>>
>>>>>You could implement a different strategy to handle this part. Some work
>>>>>was done along this path in a previous version of Simpleorm, for using a
>>>>>single JTA transaction per session. But it is not maintained.
>>>>>See simpleorm/extras/SConnectionEJB.java
>>>>>
>>>>>My question would be : what are you trying to achieve ?
>>>>>
>>>>>Franck
>>>>>
>>>>>Le vendredi 09 juillet 2010 à 17:11 +0200, Noel Grandin a écrit :
>>>>>>
>>>>>>Hi
>>>>>>
>>>>>>I'm opening multiple different databases from the same thread, which
>>>>>>is triggering this check:
>>>>>>
>>>>>>simpleorm.utils.SException$Error: Thread's SSession already open [SS
>>>>>>1.SkyMon]
>>>>>>[<mailto:0@17:08:40.976>0@17:08:40.976] !SE>: at
>>>>>>simpleorm.sessionjdbc.SSessionJdbc.innerOpen(SSessionJdbc.java:129)
>>>>>>[<mailto:0@17:08:40.976>0@17:08:40.976] !SE>: at
>>>>>>simpleorm.sessionjdbc.SSessionJdbc.open(SSessionJdbc.java:88)
>>>>>>[<mailto:0@17:08:40.976>0@17:08:40.976] !SE>: at
>>>>>>simpleorm.sessionjdbc.SSessionJdbc.open(SSessionJdbc.java:108)
>>>>>>
>>>>>>
>>>>>>What do I do?
>>>>>>
>>>>>>Thanks, Noel Grandin
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>__________________________________________________________
>>>>>>Disclaimer:
>>>>>><http://www.peralex.com/disclaimer.html>http://www.peralex.com/discla
>>>>>>imer.html
>>>>
>>>>
>>>>Spreadsheet Detective,
>>>>Southern Cross Software Queensland Pty Limited
>>>>54 Gerler Street
>>>>Bardon, Queensland 4065, Australia.
>>>>
>>>>Email: <mailto:[email protected]>[email protected]
>>>><mailto:berglas%40spreadsheetdetective.com> <http://www.SpreadsheetDetective.com>www.SpreadsheetDetective.com
>>>>Ph: +61 427 830248 (Australian Eastern Standard Time)
>>>>
>>>>"If the model seems correct only because the numbers look right,
>>>>then why build the model in the first place?"
>>>
>>>
>>>Disclaimer: <http://www.peralex.com/disclaimer.html>http://www.peralex.com/disclaimer.html
>>
>>
>>
>>
>>------------------------------------
>>
>>Yahoo! Groups Links
>>
>>
>>
>>
>
>
>
>
>----------
>Disclaimer: <http://www.peralex.com/disclaimer.html>http://www.peralex.com/disclaimer.html
>
>


Spreadsheet Detective,
Southern Cross Software Queensland Pty Limited
54 Gerler Street
Bardon, Queensland 4065, Australia.

Email: [email protected]
www.SpreadsheetDetective.com
Ph: +61 427 830248 (Australian Eastern Standard Time)

"If the model seems correct only because the numbers look right, 
then why build the model in the first place?"



------------------------------------

Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/SimpleORM/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/SimpleORM/join
    (Yahoo! ID required)

<*> To change settings via email:
    [email protected] 
    [email protected]

<*> To unsubscribe from this group, send an email to:
    [email protected]

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/