db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chux <chu...@gmail.com>
Subject Re: When to shut down a database
Date Fri, 11 Apr 2014 15:02:09 GMT
Hello Rick,

Thanks for the clarification. This really helped me a lot. I;m trying to do
a mobile client synchronizing data with a server side DB.
Yeah I think I saw it in a forum somewhere. I come across it I will let you
know.

Thanks again.

Best,
Chux


On Fri, Apr 11, 2014 at 9:41 PM, Rick Hillegas <rick.hillegas@oracle.com>wrote:

> Hi Chux,
>
> The default (and maximum) size for a CLOB is 2,147,483,647 characters. See
> http://db.apache.org/derby/docs/10.10/ref/rrefclob.html. If you have
> found a place in the documentation where some other limit is stated, could
> you let us know where that is so that we can correct that misleading
> statement?
>
> Thanks,
> -Rick
>
>
> On 4/10/14 9:09 PM, Chux wrote:
>
>> Awesome insights guys, thanks for all your help.
>>
>> BTW, I could not access the online documentation for some reason.
>> Although I read somewhere that 64k is the maximum size you can allocate a
>> clob on embedded mode. Is this correct? I would like to know what the limit
>> is.
>>
>> variable clob(64 K)
>>
>> Thanks,
>> Chux
>>
>>
>> On Thu, Apr 10, 2014 at 5:32 AM, Dag H. Wanvik <dag.wanvik@oracle.com<mailto:
>> dag.wanvik@oracle.com>> wrote:
>>
>>
>>     On 09. april 2014 17:51, Rick Hillegas wrote:
>>
>>         On 4/8/14 2:00 AM, Chux wrote:
>>
>>             Hey Dag,
>>
>>             Thanks for your insight.
>>
>>             I'm using this as an embedded DB in a Java FX desktop
>>             application. This is a dumb question but would you
>>             recommend shutting down the database ever after a
>>             transaction? Like after you create a record then you shut
>>             it down after commit.
>>
>>         Depends on the application. If the database holds some kind of
>>         infrequently referenced metadata, so that say, it is only
>>         queried or updated once a day, then you could consider an "on
>>         demand" model where the database is booted for each
>>         query/update, then the query results are returned, then the
>>         database is shut down so that it doesn't consume any
>>         resources. The big extra cost of an "on demand" database would
>>         be this:  query/update time would be substantially longer
>>         since every query/update involves booting the database,
>>         compiling the query/update, and gracefully closing the
>>         database; that cost is on top of the steady-state cost of
>>         running a pre-compiled query/update.
>>
>>     In such a scenario one might want to shut down the engine, too,
>>     not just the database.
>>     Note that shutting down the database will resources, but if the
>>     engine is still running, one can further release resources by
>>     shutting that down as well.
>>
>>     Cf.
>>     http://db.apache.org/derby/docs/10.10/devguide/tdevdvlp20349.html
>>     (engine shutdown)
>>     and
>>     http://db.apache.org/derby/docs/10.10/devguide/tdevdvlp40464.html
>>     (shutdown database)
>>
>>     Thanks,
>>     Dag
>>
>>
>>
>>
>>
>>         Hope this helps,
>>         -Rick
>>
>>
>>             Best,
>>             Chux
>>
>>
>>
>>             On Tue, Apr 8, 2014 at 12:32 AM, Dag H. Wanvik
>>             <dag.wanvik@oracle.com <mailto:dag.wanvik@oracle.com>
>>             <mailto:dag.wanvik@oracle.com
>>
>>             <mailto:dag.wanvik@oracle.com>>> wrote:
>>
>>
>>                 On 06. april 2014 21:02, George Toma wrote:
>>
>>                     Hi Chux,
>>
>>                     In my opinion  the example from  app.  referred at
>>                 commit the
>>                     transaction OR close the connection ( a connection
>>                 could be
>>                     transacted too ), and not to shutdown the db. If
>>                 the business
>>                     rule specifies that the db. needs to be shutdown
>>                 when the app. is
>>                     shutdown, then so be it.
>>
>>                     Normally the db is not shutdown, not even when the
>>                 app is down.
>>
>>
>>                 This is true for a client/server application. For use with
>>                 embedded Derby, one would normally close down the
>>             database (and
>>                 the database engine) before exiting the application.
>>             If one
>>                 neglects to do so,
>>                 one would see longer start-up times as Dyre indicated.
>>
>>                 Thanks,
>>                 Dag
>>
>>
>>
>>                     Cheers,
>>                     George
>>                     On Sunday, April 6, 2014 7:14 PM, Chux
>>                 <chux18@gmail.com <mailto:chux18@gmail.com>>
>>                 <mailto:chux18@gmail.com <mailto:chux18@gmail.com>>
>> wrote:
>>                     Hello guys,
>>
>>                     I read in a sample app that you've got to shutdown
>>                 a database. I
>>                     was just confused if you need to shut it down on
>>                 every connection
>>                     transaction or just shut it down on application
>>                 close, in my case
>>                     a desktop applicaiton.
>>
>>                     Best,
>>                     Chux
>>
>>
>>
>>
>>
>>
>>
>>
>

Mime
View raw message