dev@glassfish.java.net

Re: derby startup when domain is started

From: Marina Vatkina <marina.vatkina_at_oracle.com>
Date: Thu, 23 Sep 2010 14:15:57 -0700

Tom,

There is no good reason to load derby jars before they are used.

HTH,
-marina

Sathyan Catari wrote:
> Yes, I understand that "embedded" means same VM, was trying to see if
> it was one of the reasons as an answer to Tim's original question.
>
> Thanks
> Sathyan
>
> On 9/23/10 12:51 PM, Marina Vatkina wrote:
>> How would they be different than any other jdbc drivers? "embedded"
>> means in the same vm, or is it more to it in the derby embedded
>> behavior?
>>
>> thanks,
>> -marina
>>
>> Sathyan Catari wrote:
>>> Wouldn't you any way have to load the derby jar files @server
>>> startup, given that GF uses them in "embedded mode"?
>>>
>>> -Sathyan
>>>
>>>
>>> On 9/23/10 12:41 PM, Marina Vatkina wrote:
>>>> Starting with 3.0 ejb timer service does not start until there is
>>>> an app with ejb timeout that is either loaded or deployed.
>>>>
>>>> -marina
>>>>
>>>> Sathyan Catari wrote:
>>>>> It was required for storing ejb-timer data, not sure about the
>>>>> usage in 3.1.
>>>>>
>>>>> Thanks
>>>>> -Sathyan
>>>>>
>>>>> On 9/23/10 12:21 PM, Tom Mueller wrote:
>>>>>> While looking at system call traces from domain startup, I'm
>>>>>> seeing that the derby JAR files are being accessed very early,
>>>>>> i.e., before OSGi bundles are read in.
>>>>>>
>>>>>> Is this expected?
>>>>>> What causes derby to be brought into the system?
>>>>>>
>>>>>> AFAIK, there isn't anything in the startup benchmark application
>>>>>> that uses a database.
>>>>>>
>>>>>> Can we gain some improvement in startup time if we avoid bringing
>>>>>> in derby?
>>>>>>
>>>>>> Thanks.
>>>>>> Tom
>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>>
>>>>>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>>>>>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>>>>>
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>>>>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>>>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>