Re: TomEE + maven jar hell

[Romain Manni-Bucau]

If you got it maybe share it here, it can be useful for others
Le 14 déc. 2012 08:20, "robertlee"  a écrit :

> sorry, it's a maven dependency related issue, I shouldn't post the issue
> here. TomEE is great.
>
>
>
> --
> View this message in context:
> http://openejb.979440.n4.nabble.com/TomEE-maven-jar-hell-tp4659515p4659610.html
> Sent from the OpenEJB User mailing list archive at Nabble.com.
>

Re: TomEE + maven jar hell

[robertlee]

sorry, it's a maven dependency related issue, I shouldn't post the issue
here. TomEE is great.



--
View this message in context: 
http://openejb.979440.n4.nabble.com/TomEE-maven-jar-hell-tp4659515p4659610.html
Sent from the OpenEJB User mailing list archive at Nabble.com.

Re: Why are Tomcat's threads more costly than background threads?

[Howard W. Smith, Jr.]

David, I corrected that as you stated, and I made sure the code was as you
recommended, and I've updated the JIRA with test results. Windows Server
2008 64bit is still fast, Windows SErver 2003 32bit is 'still' slow and
locking the database.



On Thu, Dec 13, 2012 at 7:02 PM, David Blevins wrote:

> My bad, should be @TransactionAttribute(NOT_SUPPORTED)  -- even hard for
> me to remember the right names :)
>
> In case you're curious, reading for another day:
>
>   http://tomee.apache.org/transaction-annotations.html
>

Re: Unable to configure MYSQL resource in tomee.xml

[Romain Manni-Bucau]

Hmm, isnt the datasource in openejb mbeans?

Please check url and all the config (check tomee didnt adjust some settings)
Le 14 déc. 2012 01:34, "avrono"  a écrit :

> Hi Romain,
>
> I can see the DataSource using JMX under DataSource and also under Resource
> -> Context
>
>
> Catalina:type=DataSource,context=/PRSX,host=localhost,class=javax.sql.DataSource,name="avronDB"
>
> Is there anything specific I should be looking for ?
>
>
>
> --
> View this message in context:
> http://openejb.979440.n4.nabble.com/Unable-to-configure-MYSQL-resource-in-tomee-xml-tp4659538p4659608.html
> Sent from the OpenEJB User mailing list archive at Nabble.com.
>

Re: Unable to configure MYSQL resource in tomee.xml

[avrono]

Hi Romain, 

I can see the DataSource using JMX under DataSource and also under Resource
-> Context

Catalina:type=DataSource,context=/PRSX,host=localhost,class=javax.sql.DataSource,name="avronDB"

Is there anything specific I should be looking for ?



--
View this message in context: 
http://openejb.979440.n4.nabble.com/Unable-to-configure-MYSQL-resource-in-tomee-xml-tp4659538p4659608.html
Sent from the OpenEJB User mailing list archive at Nabble.com.

Re: Why are Tomcat's threads more costly than background threads?

[David Blevins]

On Dec 13, 2012, at 2:41 PM, "Howard W. Smith, Jr."  
wrote:

> Question...
> 
> My last/latest implementation/version of AirportShuttleProcessingBean is a
> @Stateless EJB that calls many other @Stateless EJB (DAO). Should I keep
> PersistentContext in AirportShuttleProcessingBean, or can
> AirportShuttleProcessingBean call any/all @Stateless EJB (DAO) for shortest
> transaction possiblel? I hear that a lot here in Apache/TomEE/Tomcat
> land... shortest transactions are best.

The rule of thumb is that you want the transaction to be as short as possible 
while also not jeopardizing data integrity/consistency.

As a small example, say you had to process an order from a customer that didn't 
yet exist.  Ideally, you would add the new customer information in one 
transaction, then add the order in another transaction.

The scope starts to become "too short", when we get into say processing the 
order itself with several small transactions.  You wouldn't want to insert a 
new bare "Order" as one transaction, then add each "Item" in an order as 
separate transactions.  The result of a failure to complete is a half processed 
order which is clearly a non-recoverable situation.


One somewhat unrelated note, I did notice several flush() commands in your 
code.  All data is automatically flushed at the end of the transaction, so 
there should be no need for this can and in fact calling it excessively can 
cause performance issues.  It can mean the difference between one trip to the 
database and one hundred trips to the database.

Having said that, *do not* remove them now.  Wait till we are clearly at a 
state  where we have successfully split the transactions and things work.  Once 
we reach that milestone and all works and code is checked in, then give the 
"remove excess flush() calls" optimization a try.


-David

Re: Why are Tomcat's threads more costly than background threads?

[David Blevins]

On Dec 13, 2012, at 3:57 PM, "Howard W. Smith, Jr."  
wrote:

> David, I did as you recommended. I got an exception related to the ejbTimer
> and JTA. please see my latest 2 post on the JIRA.

My bad, should be @TransactionAttribute(NOT_SUPPORTED)  -- even hard for me to 
remember the right names :)

In case you're curious, reading for another day:

  http://tomee.apache.org/transaction-annotations.html


-David

Re: Why are Tomcat's threads more costly than background threads?

[Howard W. Smith, Jr.]

David, I did as you recommended. I got an exception related to the ejbTimer
and JTA. please see my latest 2 post on the JIRA.

https://issues.apache.org/jira/browse/OPENEJB-1968

Need to leave my desk for little bit. Thanks.

On Thu, Dec 13, 2012 at 4:06 PM, David Blevins wrote:

> If you're willing to go back to the original version of the code and do
> *only* the suggestions given, I think we can get this easily sorted out
> today.

Re: Unable to configure MYSQL resource in tomee.xml

[avrono]

I will try do so ... Let you know



--
View this message in context: 
http://openejb.979440.n4.nabble.com/Unable-to-configure-MYSQL-resource-in-tomee-xml-tp4659538p4659604.html
Sent from the OpenEJB User mailing list archive at Nabble.com.

Re: openejb.xml

[Romain Manni-Bucau]

wrong "foo" is the standard.
java:... names are not. You can use java:openejb/Resource/foo too i
guess...but well not better ;)

OpenEJB 4.5.1 should support java:global or java:app (can't remember)
names for datasources. But well clearly not something portable between
application servers.

about root utl we can't guess it from arquillian so the heuristic is
to use the place where persistence.xml is (well it is the marker then
we update it).

You can't compare openejb to jboss or was because openejb arquilliana
dapter doesn't dump the archive on the disk. If you need it use tomee
remote arquillian adapter (or embedded) maybe


Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
LinkedIn: http://fr.linkedin.com/in/rmannibucau
Github: https://github.com/rmannibucau



2012/12/13 Baker, Trevor :
> foo

RE: openejb.xml

[Baker, Trevor]

Hi Romain,

I agree Arquillian in fully embedded is not easy to get right. Been playing 
around with it for weeks. :-) Not only that but OpenEJB has to deal with 
different JPA providers too. I understand the desire to load stuff off of 
file://... because don't have to re-package all the code into a jar://... (or 
some protocol that jives with ShrinkWrap archives) but I think packaging it up 
would solve some Arquillian issues (at least for Hibernate ... not sure about 
other JPA providers). Thoughts?

Ok, foo is the standard for *OpenEJB*. 
OpenEJB creates the JNDI entry 'java:/openejb/Resource/foo' for the JPA 
providers to use. Why can't I provide my own *explicit* JNDI path (regardless 
of how ugly my JNDI path is :-) ? I've worked with Weblogic and JBoss and they 
don't swap it out like OpenEJB does. It makes my config structure easier 
because then all OpenEJB and JBoss config aligns better and I have fewer 
overrides.

Sounds like OpenEJB 4.5.1 doesn't support explicit JNDI paths for the 
jta-data-source & non-jta-data-source? If it doesn't I'll create a Jira because 
I think it should be something for consideration for a future release.

Trev

-Original Message-
From: Romain Manni-Bucau [mailto:rmannibu...@gmail.com] 
Sent: Thursday, December 13, 2012 1:50 PM
To: users@openejb.apache.org
Subject: Re: openejb.xml

about root url with 1.5.1 it should be the build dir (well we look at classpath 
persistence.xml so if resources is in the classpath...) but you can avoid it 
specifying your entities. From arquillian in fully embedded mode that's not so 
easy to get it right (you can specify it using new StringAsset(..) so no root 
url)

about the datasource just define a resource called "foo" (whatever you want but 
not java:foo) and use "foo" in the persistence.xml (java:/my/own/jdbc/dbUnitDS 
is not standard in this place)

Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
LinkedIn: http://fr.linkedin.com/in/rmannibucau
Github: https://github.com/rmannibucau



2012/12/13 Baker, Trevor :
> I'm hoping to use config files instead of doing it programmatically.
>
> I tried a src/test/resources/dbUnit-persistence.xml once before with 
> Arquillian putting it into the archive as META-INF/persistence.xml. Sadly, 
> the PU's root url passed to hibernate was incorrect and hibernate didn't 
> obviously find my src/main/java/... @Entity tagged classes. So went the 
> jndi.properties route and overriding entries in 
> src/main/resources/META-INF/persistence.xml. I'll get a test case for you. 
> IIRC, I think it used file://.../src/test/resources as the root url instead 
> of a virtual Jar.
>
> For the PU's java:/my/own/jdbc/dbUnitDS, 
> OpenEJB does some magic in the back and replaces it. Is there a way I can 
> keep it and I can supply the data source? I got a JNDI tree importer for 
> @Resource(lookup) stuff so I can throw in a DBCP too.
>
> Thanks,
> Trev
>
> -Original Message-
> From: Romain Manni-Bucau [mailto:rmannibu...@gmail.com]
> Sent: Thursday, December 13, 2012 12:40 PM
> To: users@openejb.apache.org
> Subject: Re: openejb.xml
>
> hmm jndi.properties is not managed by openejb directly in your case 
> byt InitialContext IIRC
>
> why not simply passing these properties to openejb when starting the 
> container?
>
> Note: "new" EJBContainer API ignores jndi.properties IIRC
>
> for the datasource you can create a conf folder (in ".") and add 
> openejb.xml file. For hibernate you'll need to add it somewhere else 
> (you can use altdd to define a test.persistence.xml normally)
>
> Romain Manni-Bucau
> Twitter: @rmannibucau
> Blog: http://rmannibucau.wordpress.com/
> LinkedIn: http://fr.linkedin.com/in/rmannibucau
> Github: https://github.com/rmannibucau
>
>
>
> 2012/12/13 Neale :
>> Hi Trevor,
>>
>> Can you tell us your changes/findings so we can adjust the docs to 
>> make it easier for everyone else?
>>
>> Best Regards,
>> Neale
>>
>>
>>
>> - Original Message - From: "Baker, Trevor"
>> 
>> To: 
>> Sent: Friday, December 14, 2012 7:10 AM
>> Subject: RE: openejb.xml
>>
>>
>>
>> Fixed some line-ending weirdness.
>>
>> -Original Message-
>> From: Baker, Trevor [mailto:crba...@mail.ubc.ca]
>> Sent: Thursday, December 13, 2012 12:07 PM
>> To: users@openejb.apache.org
>> Subject: openejb.xml
>>
>> Hi,
>>
>> I have the following jndi.properties:
>>
>> 
>> java.naming.factory.initial=org.apache.openejb.client.LocalInitialCon
>> t
>> extFactory
>>
>> # create a new data source at: java:/openejb/Resource/dbUnitDS 
>> dbUnitDS=new://Resource?type=DataSource
>> dbUnitDS.JdbcUrl=jdbc:h2:mem:arquillian;DB_CLOSE_DELAY=-1
>> dbUnitDS.JdbcDriver=org.h2.Driver
>> dbUnitDS.JtaManaged=true
>>
>> # add properties for the persistence unit 
>> test.hibernate.dialect=org.hibernate.dialect.H2Dialect
>> test.hibernate.hbm2ddl.auto=create-drop
>> test.hibernate.id.new_generator_mappings=true
>> ---
>>
>> Unfortunately, jndi.properties is interfering with non-openejb

Re: Unable to configure MYSQL resource in tomee.xml

[Romain Manni-Bucau]

can you connect through JMX to check the config of the datasource is
fine please?

maybe you'll need to add jmxEnabled = true in the properties of the
datasource definition

Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
LinkedIn: http://fr.linkedin.com/in/rmannibucau
Github: https://github.com/rmannibucau



2012/12/13 avrono :
> Romain,
>
> Yes it is there. I can connect using DriverManager...
>
>
>
> --
> View this message in context: 
> http://openejb.979440.n4.nabble.com/Unable-to-configure-MYSQL-resource-in-tomee-xml-tp4659538p4659596.html
> Sent from the OpenEJB User mailing list archive at Nabble.com.

Re: Unable to configure MYSQL resource in tomee.xml

[avrono]

Romain,

Yes it is there. I can connect using DriverManager...



--
View this message in context: 
http://openejb.979440.n4.nabble.com/Unable-to-configure-MYSQL-resource-in-tomee-xml-tp4659538p4659596.html
Sent from the OpenEJB User mailing list archive at Nabble.com.

Re: Why are Tomcat's threads more costly than background threads?

[David Blevins]

On Dec 13, 2012, at 2:01 PM, "Howard W. Smith, Jr."  
wrote:

> Thanks for the response. Guess what... the 2 beans along with the names and
> all... is exactly what I did 'yesterday', the only thing I did 'not' do was
> mark each of the beans according to what you mentioned.

Right, the annotations are a critical part.  Splitting the code and not 
changing the TransactionAttribute annotations as noted would essentially still 
result in one big transaction (i.e. no change).

Educational point; when no @TransactionAttribute is specified on an EJB, it 
defaults to @TransactionAttribute(REQUIRED)

REQUIRED basically means "join the existing transaction if possible, otherwise 
create one".  So EmailSessionBean would create a transaction in the @Schedule 
method and every method invocation on AirportShuttleRequestProcessorBean would 
just join the existing transaction.

The result:
 - one big transaction that locks all tables and doesn't let them go till 
getEmails completes
 - if email 1 from Joe fails, all email processing will fail and rollback when 
getEmail completes

So aside from a performance problem, there's a very real business logic problem.

Splitting them *and* adjusting the transaction settings will fix the business 
problem and likely help with the performance problem.  The big difference of 2 
seconds on 64-bit vs several minutes on a 32-bit is alarming and very likely a 
system issue of some kind.  That said, going down this path of shrinking 
transaction scope will help zero in on where the problem occurs.


-David

Re: Why are Tomcat's threads more costly than background threads?

[David Blevins]

On Dec 13, 2012, at 1:53 PM, David Blevins  wrote:

> 
> On Dec 13, 2012, at 1:17 PM, "Howard W. Smith, Jr."  
> wrote:
> 
>> David,
>> 
>> 1. definitely not using @Asynchronous; that was no good at all
>> 
>> 2. Actually, it was 2 seconds on the Windows Server 2008 64-bit 16GB RAM...
>> always
>> 
>> 3. Always 5 to 10 minutes to process 1 or 2 emails on Windows Server 2003
>> 32-bit 4GB RAM
> 
> Good info thanks.
> 
>> 4. As noted on the JIRA, I tried the TransactionAttribute NEVER and
>> REQUIRES_NEW on @Stateless EJB that was all invoked via @Schedule, and same
>> test results, which are The EJB timer rolls back the transaction, and
>> every database operation that the EmailStatelessBean completed...prior to
>> @Schedule rolling back the transaction.
> 
> Right, that suggestion was never implemented as it was intended.  Changing 
> the TransactionAttribute alone will do nothing.  What we need is to 1) 
> prevent a transaction from being started and 2) creating a new and smaller 
> transaction scope through a small code rework.
> 
> The ApplicationScoped check backfired because it has the effect of locking 
> tables for much longer.  We want to process each "email" in an individual 
> transaction and move away from one big transaction.  This is really the most 
> critical step to take, no other steps or workarounds matter at this phase of 
> the problem.
> 
> Let's try this:
> 
>  - Go back to the very original 5-10 minutes 32-bit code
> 
>  - Split EmailSessionBean into two beans
> 
>  - EmailSessionBean
> - will be marked @TransactionAttribute(NEVER)
> - will no longer have an @PersistenceContext EntityManager reference
>  - AirportShuttleRequestProcessorBean
> - will be marked @TransactionAttribute(REQUIRES_NEW)
> - will have only one public method, `createOrderForAirportShuttle`
> - will do all persistence processing
> 
> The EmailSessionBean will have an @EJB reference to the new 
> AirportShuttleRequestProcessorBean.  Effectively, we're splitting the code 
> that does the contacting the of the email server from the code that contacts 
> the database and we're creating several much smaller transactions.

And one more tweak.  Let's change the EmailSessionBean to type @Singleton and 
add @Lock(WRITE) to our `getEmails()` method.

We're doing this to ensure that two `getEmail()` invocations cannot possibly 
happen at the same time.  This is not necessarily the case now, but this can 
easily occur if the `getEmails()` method takes longer than the configured time 
of every 10 minutes.  It can also occur if the time gets shorted, to say 2 
minutes.

With switching our EmailSessionBean bean to type @Singleton and ensuring 
@Lock(WRITE) on the `getEmails()` method, once things are working well we could 
effectively dramatically reduce the delay between firings to something far more 
aggressive than 10 minutes (say 2 or 5 minutes) and still be safe.  The 
combination of @Singleton/@Lock(WRITE) guarantees that method will only ever be 
active one-at-a-time in the entire application.


-David

Re: Why are Tomcat's threads more costly than background threads?

[Howard W. Smith, Jr.]

David,

Thanks for the response. Guess what... the 2 beans along with the names and
all... is exactly what I did 'yesterday', the only thing I did 'not' do was
mark each of the beans according to what you mentioned.

I will try that, ASAP might not be able to report about it until a
little later. I want the @Schedule approach along with a user-initiated
approach. I'm coding the user initiated approach right now.

The original approach will definitely serve for background processing.

Thanks,
Howard

On Thu, Dec 13, 2012 at 4:53 PM, David Blevins wrote:

> Let's try this:
>
>   - Go back to the very original 5-10 minutes 32-bit code
>
>   - Split EmailSessionBean into two beans
>
>   - EmailSessionBean
>  - will be marked @TransactionAttribute(NEVER)
>  - will no longer have an @PersistenceContext EntityManager
> reference
>   - AirportShuttleRequestProcessorBean
>  - will be marked @TransactionAttribute(REQUIRES_NEW)
>  - will have only one public method, `createOrderForAirportShuttle`
>  - will do all persistence processing
>
> The EmailSessionBean will have an @EJB reference to the new
> AirportShuttleRequestProcessorBean.  Effectively, we're splitting the code
> that does the contacting the of the email server from the code that
> contacts the database and we're creating several much smaller transactions.
>

Re: Why are Tomcat's threads more costly than background threads?

[David Blevins]

On Dec 13, 2012, at 1:17 PM, "Howard W. Smith, Jr."  
wrote:

> David,
> 
> 1. definitely not using @Asynchronous; that was no good at all
> 
> 2. Actually, it was 2 seconds on the Windows Server 2008 64-bit 16GB RAM...
> always
> 
> 3. Always 5 to 10 minutes to process 1 or 2 emails on Windows Server 2003
> 32-bit 4GB RAM

Good info thanks.

> 4. As noted on the JIRA, I tried the TransactionAttribute NEVER and
> REQUIRES_NEW on @Stateless EJB that was all invoked via @Schedule, and same
> test results, which are The EJB timer rolls back the transaction, and
> every database operation that the EmailStatelessBean completed...prior to
> @Schedule rolling back the transaction.

Right, that suggestion was never implemented as it was intended.  Changing the 
TransactionAttribute alone will do nothing.  What we need is to 1) prevent a 
transaction from being started and 2) creating a new and smaller transaction 
scope through a small code rework.

The ApplicationScoped check backfired because it has the effect of locking 
tables for much longer.  We want to process each "email" in an individual 
transaction and move away from one big transaction.  This is really the most 
critical step to take, no other steps or workarounds matter at this phase of 
the problem.

Let's try this:

  - Go back to the very original 5-10 minutes 32-bit code

  - Split EmailSessionBean into two beans

  - EmailSessionBean
 - will be marked @TransactionAttribute(NEVER)
 - will no longer have an @PersistenceContext EntityManager reference
  - AirportShuttleRequestProcessorBean
 - will be marked @TransactionAttribute(REQUIRES_NEW)
 - will have only one public method, `createOrderForAirportShuttle`
 - will do all persistence processing

The EmailSessionBean will have an @EJB reference to the new 
AirportShuttleRequestProcessorBean.  Effectively, we're splitting the code that 
does the contacting the of the email server from the code that contacts the 
database and we're creating several much smaller transactions.


-David

Re: openejb.xml

[Romain Manni-Bucau]

about root url with 1.5.1 it should be the build dir (well we look at
classpath persistence.xml so if resources is in the classpath...) but
you can avoid it specifying your entities. From arquillian in fully
embedded mode that's not so easy to get it right (you can specify it
using new StringAsset(..) so no root url)

about the datasource just define a resource called "foo" (whatever you
want but not java:foo) and use "foo" in the persistence.xml
(java:/my/own/jdbc/dbUnitDS is not standard in this place)

Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
LinkedIn: http://fr.linkedin.com/in/rmannibucau
Github: https://github.com/rmannibucau



2012/12/13 Baker, Trevor :
> I'm hoping to use config files instead of doing it programmatically.
>
> I tried a src/test/resources/dbUnit-persistence.xml once before with 
> Arquillian putting it into the archive as META-INF/persistence.xml. Sadly, 
> the PU's root url passed to hibernate was incorrect and hibernate didn't 
> obviously find my src/main/java/... @Entity tagged classes. So went the 
> jndi.properties route and overriding entries in 
> src/main/resources/META-INF/persistence.xml. I'll get a test case for you. 
> IIRC, I think it used file://.../src/test/resources as the root url instead 
> of a virtual Jar.
>
> For the PU's java:/my/own/jdbc/dbUnitDS, 
> OpenEJB does some magic in the back and replaces it. Is there a way I can 
> keep it and I can supply the data source? I got a JNDI tree importer for 
> @Resource(lookup) stuff so I can throw in a DBCP too.
>
> Thanks,
> Trev
>
> -Original Message-
> From: Romain Manni-Bucau [mailto:rmannibu...@gmail.com]
> Sent: Thursday, December 13, 2012 12:40 PM
> To: users@openejb.apache.org
> Subject: Re: openejb.xml
>
> hmm jndi.properties is not managed by openejb directly in your case byt 
> InitialContext IIRC
>
> why not simply passing these properties to openejb when starting the 
> container?
>
> Note: "new" EJBContainer API ignores jndi.properties IIRC
>
> for the datasource you can create a conf folder (in ".") and add openejb.xml 
> file. For hibernate you'll need to add it somewhere else (you can use altdd 
> to define a test.persistence.xml normally)
>
> Romain Manni-Bucau
> Twitter: @rmannibucau
> Blog: http://rmannibucau.wordpress.com/
> LinkedIn: http://fr.linkedin.com/in/rmannibucau
> Github: https://github.com/rmannibucau
>
>
>
> 2012/12/13 Neale :
>> Hi Trevor,
>>
>> Can you tell us your changes/findings so we can adjust the docs to
>> make it easier for everyone else?
>>
>> Best Regards,
>> Neale
>>
>>
>>
>> - Original Message - From: "Baker, Trevor"
>> 
>> To: 
>> Sent: Friday, December 14, 2012 7:10 AM
>> Subject: RE: openejb.xml
>>
>>
>>
>> Fixed some line-ending weirdness.
>>
>> -Original Message-
>> From: Baker, Trevor [mailto:crba...@mail.ubc.ca]
>> Sent: Thursday, December 13, 2012 12:07 PM
>> To: users@openejb.apache.org
>> Subject: openejb.xml
>>
>> Hi,
>>
>> I have the following jndi.properties:
>>
>> 
>> java.naming.factory.initial=org.apache.openejb.client.LocalInitialCont
>> extFactory
>>
>> # create a new data source at: java:/openejb/Resource/dbUnitDS
>> dbUnitDS=new://Resource?type=DataSource
>> dbUnitDS.JdbcUrl=jdbc:h2:mem:arquillian;DB_CLOSE_DELAY=-1
>> dbUnitDS.JdbcDriver=org.h2.Driver
>> dbUnitDS.JtaManaged=true
>>
>> # add properties for the persistence unit
>> test.hibernate.dialect=org.hibernate.dialect.H2Dialect
>> test.hibernate.hbm2ddl.auto=create-drop
>> test.hibernate.id.new_generator_mappings=true
>> ---
>>
>> Unfortunately, jndi.properties is interfering with non-openejb unit
>> tests in the project. Would like to convert to openejb.xml but need
>> some help. Can someone send back the openejb.xml equivalent. I'm
>> assuming I can place in src/test/resources/openejb.xml.
>>
>> Not being lazy. Just can't find any good resources. Would be nice if
>> this page could have a sample openejb.xml:
>> http://tomee.apache.org/embedded-configuration.html
>>
>> Thanks,
>> Trev

RE: openejb.xml

[Baker, Trevor]

I'm hoping to use config files instead of doing it programmatically.

I tried a src/test/resources/dbUnit-persistence.xml once before with Arquillian 
putting it into the archive as META-INF/persistence.xml. Sadly, the PU's root 
url passed to hibernate was incorrect and hibernate didn't obviously find my 
src/main/java/... @Entity tagged classes. So went the jndi.properties route and 
overriding entries in src/main/resources/META-INF/persistence.xml. I'll get a 
test case for you. IIRC, I think it used file://.../src/test/resources as the 
root url instead of a virtual Jar.

For the PU's java:/my/own/jdbc/dbUnitDS, 
OpenEJB does some magic in the back and replaces it. Is there a way I can keep 
it and I can supply the data source? I got a JNDI tree importer for 
@Resource(lookup) stuff so I can throw in a DBCP too.

Thanks,
Trev

-Original Message-
From: Romain Manni-Bucau [mailto:rmannibu...@gmail.com] 
Sent: Thursday, December 13, 2012 12:40 PM
To: users@openejb.apache.org
Subject: Re: openejb.xml

hmm jndi.properties is not managed by openejb directly in your case byt 
InitialContext IIRC

why not simply passing these properties to openejb when starting the container?

Note: "new" EJBContainer API ignores jndi.properties IIRC

for the datasource you can create a conf folder (in ".") and add openejb.xml 
file. For hibernate you'll need to add it somewhere else (you can use altdd to 
define a test.persistence.xml normally)

Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
LinkedIn: http://fr.linkedin.com/in/rmannibucau
Github: https://github.com/rmannibucau



2012/12/13 Neale :
> Hi Trevor,
>
> Can you tell us your changes/findings so we can adjust the docs to 
> make it easier for everyone else?
>
> Best Regards,
> Neale
>
>
>
> - Original Message - From: "Baker, Trevor" 
> 
> To: 
> Sent: Friday, December 14, 2012 7:10 AM
> Subject: RE: openejb.xml
>
>
>
> Fixed some line-ending weirdness.
>
> -Original Message-
> From: Baker, Trevor [mailto:crba...@mail.ubc.ca]
> Sent: Thursday, December 13, 2012 12:07 PM
> To: users@openejb.apache.org
> Subject: openejb.xml
>
> Hi,
>
> I have the following jndi.properties:
>
> 
> java.naming.factory.initial=org.apache.openejb.client.LocalInitialCont
> extFactory
>
> # create a new data source at: java:/openejb/Resource/dbUnitDS 
> dbUnitDS=new://Resource?type=DataSource
> dbUnitDS.JdbcUrl=jdbc:h2:mem:arquillian;DB_CLOSE_DELAY=-1
> dbUnitDS.JdbcDriver=org.h2.Driver
> dbUnitDS.JtaManaged=true
>
> # add properties for the persistence unit 
> test.hibernate.dialect=org.hibernate.dialect.H2Dialect
> test.hibernate.hbm2ddl.auto=create-drop
> test.hibernate.id.new_generator_mappings=true
> ---
>
> Unfortunately, jndi.properties is interfering with non-openejb unit 
> tests in the project. Would like to convert to openejb.xml but need 
> some help. Can someone send back the openejb.xml equivalent. I'm 
> assuming I can place in src/test/resources/openejb.xml.
>
> Not being lazy. Just can't find any good resources. Would be nice if 
> this page could have a sample openejb.xml:
> http://tomee.apache.org/embedded-configuration.html
>
> Thanks,
> Trev

Re: Simple Netbeans CDI Web Application Not Working

[Kay Wrobel]

So, I haven't settled on any particular EE container. I like the fact I 
can manage the different Glassfish aspects via a web interface and that 
it is so "reference" and just works. I disagree with the not working 
statement as the nature of this thread is: it didn't work out of the box 
with TomEE for me. I know Tomcat has a web interface, too, but it' s 
very basic. Obviously I have been spoiled by point'n'click M$ software, 
but I am also running a Linux workstation with a Windows 7 VM just for 
the .NET stuff. So you see my clear preference right there. And 
command-line is second nature to me.


Anyway, this is for a different discussion, I think.

Thanks guys for helping me with this. It probably won't be the last time 
I'm posting to this user group as I clearly intend on getting more 
involved with Java and TomEE.


Kay

On 12/13/2012 03:25 PM, Howard W. Smith, Jr. wrote:

I recommend 1.5.1 and I prefer it over Glassfish? Why, because I don't make
sticking with it...to make it work.

TomEE and CDI-managed-beans and the not-so-real Apache Derby database on my
slow/old Windows Server 2003 32bit 4GB RAM is performing just as good as
Glassfish 3.1.2.2. I'm just learning 'how' to use TomEE, correctly and
efficiently.

Please make that sale.. TomEE/CDI... defintely not .NET. :)

Glassfish/WELD for CDI? i was not able to make it work at all, too hard,
too complicated... someone else told me recently, they heard all my
buzz/chatter in many different forums, they had/have Glassfish/WELD for CDI
and it's working good in production forthem, but they tried
TomEE/CDI-managed-beans, and that person said... it 'feels' faster than
Glassfish/WELD.

I like the tomEE committers big time! go with tomEE. :)


On Thu, Dec 13, 2012 at 4:15 PM, Romain Manni-Bucau
wrote:


you'll not get issue with your management, the 1.5.1 release passed,
we just wait Jean-Louis to push binaries on repo1 :)

Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
LinkedIn: http://fr.linkedin.com/in/rmannibucau
Github: https://github.com/rmannibucau



2012/12/13 Kay Wrobel :

It does when you check the "Enable Context and Dependency Injection"

check

box.


  Kay Wrobel

MIS Associate
*Hawk Electronics, Inc.*
800-THE-HAWK
800-843-4295
kwro...@hawkusa.com


On 12/13/2012 03:08 PM, Romain Manni-Bucau wrote:

Question from a none netbeans user: when creating a new JavaEE 6
project netbeans doesn't create a beans.xml?

Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
LinkedIn: http://fr.linkedin.com/in/rmannibucau
Github: https://github.com/rmannibucau



2012/12/13 Howard W. Smith, Jr. :

I struggled getting mine to work as well, but I was advised to either

add

beans.xml to WEB-INF or META-INF folder.

I learned that in NetBeans, for META-INF, you create a new folder in

the

same folder that contain all your java code. Netbeans does not like
META-INF/beans.xml, you get squiggly lines etc when trying to code, so
the
full path of mine is as follows:

C:\Users\Public\NetBeansProjects\mcms_tomee\web\WEB-INF\beans.xml

Empty beans.xml would be like the following:



http://java.sun.com/xml/ns/javaee";
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
 xsi:schemaLocation="http://java.sun.com/xml/ns/javaee
http://java.sun.com/xml/ns/javaee/beans_1_0.xsd";>





On Thu, Dec 13, 2012 at 3:56 PM, Kay Wrobel 

wrote:

Now CDI is item number one in the feature list of TomEE Web Profile

and

has been since version 1.0 if I remember correctly. I just can't get

it

to
work...



--

--
The information in this e-mail is confidential and is intended solely for
the addressee(s). Access to this email by anyone else is unauthorized. If
you are not an intended recipient, you may not print, save or otherwise
store the e-mail or any of the contents thereof in electronic or physical
form, nor copy, use or disseminate the information contained in the

email.

If you are not an intended recipient,  please notify the sender of this
email immediately.



--

--
The information in this e-mail is confidential and is intended solely for 
the addressee(s). Access to this email by anyone else is unauthorized. If 
you are not an intended recipient, you may not print, save or otherwise 
store the e-mail or any of the contents thereof in electronic or physical 
form, nor copy, use or disseminate the information contained in the email. 
If you are not an intended recipient,  please notify the sender of this 
email immediately.

Re: Simple Netbeans CDI Web Application Not Working

[Howard W. Smith, Jr.]

I recommend 1.5.1 and I prefer it over Glassfish? Why, because I don't make
sticking with it...to make it work.

TomEE and CDI-managed-beans and the not-so-real Apache Derby database on my
slow/old Windows Server 2003 32bit 4GB RAM is performing just as good as
Glassfish 3.1.2.2. I'm just learning 'how' to use TomEE, correctly and
efficiently.

Please make that sale.. TomEE/CDI... defintely not .NET. :)

Glassfish/WELD for CDI? i was not able to make it work at all, too hard,
too complicated... someone else told me recently, they heard all my
buzz/chatter in many different forums, they had/have Glassfish/WELD for CDI
and it's working good in production forthem, but they tried
TomEE/CDI-managed-beans, and that person said... it 'feels' faster than
Glassfish/WELD.

I like the tomEE committers big time! go with tomEE. :)


On Thu, Dec 13, 2012 at 4:15 PM, Romain Manni-Bucau
wrote:

> you'll not get issue with your management, the 1.5.1 release passed,
> we just wait Jean-Louis to push binaries on repo1 :)
>
> Romain Manni-Bucau
> Twitter: @rmannibucau
> Blog: http://rmannibucau.wordpress.com/
> LinkedIn: http://fr.linkedin.com/in/rmannibucau
> Github: https://github.com/rmannibucau
>
>
>
> 2012/12/13 Kay Wrobel :
> > It does when you check the "Enable Context and Dependency Injection"
> check
> > box.
> >
> >
> >  Kay Wrobel
> >
> > MIS Associate
> > *Hawk Electronics, Inc.*
> > 800-THE-HAWK
> > 800-843-4295
> > kwro...@hawkusa.com
> >
> >
> > On 12/13/2012 03:08 PM, Romain Manni-Bucau wrote:
> >>
> >> Question from a none netbeans user: when creating a new JavaEE 6
> >> project netbeans doesn't create a beans.xml?
> >>
> >> Romain Manni-Bucau
> >> Twitter: @rmannibucau
> >> Blog: http://rmannibucau.wordpress.com/
> >> LinkedIn: http://fr.linkedin.com/in/rmannibucau
> >> Github: https://github.com/rmannibucau
> >>
> >>
> >>
> >> 2012/12/13 Howard W. Smith, Jr. :
> >>>
> >>> I struggled getting mine to work as well, but I was advised to either
> add
> >>> beans.xml to WEB-INF or META-INF folder.
> >>>
> >>> I learned that in NetBeans, for META-INF, you create a new folder in
> the
> >>> same folder that contain all your java code. Netbeans does not like
> >>> META-INF/beans.xml, you get squiggly lines etc when trying to code, so
> >>> the
> >>> full path of mine is as follows:
> >>>
> >>> C:\Users\Public\NetBeansProjects\mcms_tomee\web\WEB-INF\beans.xml
> >>>
> >>> Empty beans.xml would be like the following:
> >>>
> >>>
> >>> 
> >>> http://java.sun.com/xml/ns/javaee";
> >>> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> >>> xsi:schemaLocation="http://java.sun.com/xml/ns/javaee
> >>> http://java.sun.com/xml/ns/javaee/beans_1_0.xsd";>
> >>> 
> >>>
> >>>
> >>>
> >>>
> >>> On Thu, Dec 13, 2012 at 3:56 PM, Kay Wrobel 
> wrote:
> >>>
>  Now CDI is item number one in the feature list of TomEE Web Profile
> and
>  has been since version 1.0 if I remember correctly. I just can't get
> it
>  to
>  work...
> >
> >
> >
> > --
> >
> > --
> > The information in this e-mail is confidential and is intended solely for
> > the addressee(s). Access to this email by anyone else is unauthorized. If
> > you are not an intended recipient, you may not print, save or otherwise
> > store the e-mail or any of the contents thereof in electronic or physical
> > form, nor copy, use or disseminate the information contained in the
> email.
> > If you are not an intended recipient,  please notify the sender of this
> > email immediately.
>

Re: Simple Netbeans CDI Web Application Not Working

[Romain Manni-Bucau]

personally i use Intellij Idea (Ultimate but to be honest i only use
community features excepting for spring integration which is awesome).

i love the tomee maven plugin (@others: i know :p) and abuse of it

I think Jon is using eclipse
@Jon: right?

Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
LinkedIn: http://fr.linkedin.com/in/rmannibucau
Github: https://github.com/rmannibucau



2012/12/13 Kay Wrobel :
> Hey, that's good. I take it you're an Eclipse user then? I really want to
> like Eclipse, but I find there are just too many things where I have to lay
> my hands on that would work out of the box with Netbeans. At the same time,
> Netbeans currentlt doesn't let me generate JSF pages from Entity Beans if
> the server is not a full Java EE server, and it just doesn't recognize TomEE
> as one. That's I think handled better in Eclipse. So yeah, I'm like
> inbetween because I'm new to Java EE development. I come from Visual Studio
> .NET 2010 and, well, it is mighty refined let me tell you. But we're
> investigating getting away from that to a more open platform-independent
> solution. And Java EE fits really well. Plus Primefaces... it's sweet sweet
> sweet.
>
> Kay
>
>
> On 12/13/2012 03:15 PM, Romain Manni-Bucau wrote:
>>
>> you'll not get issue with your management, the 1.5.1 release passed,
>> we just wait Jean-Louis to push binaries on repo1 :)
>>
>> Romain Manni-Bucau
>> Twitter: @rmannibucau
>> Blog: http://rmannibucau.wordpress.com/
>> LinkedIn: http://fr.linkedin.com/in/rmannibucau
>> Github: https://github.com/rmannibucau
>>
>>
>>
>> 2012/12/13 Kay Wrobel :
>>>
>>> It does when you check the "Enable Context and Dependency Injection"
>>> check
>>> box.
>>>
>>>
>>>   Kay Wrobel
>>>
>>> MIS Associate
>>> *Hawk Electronics, Inc.*
>>> 800-THE-HAWK
>>> 800-843-4295
>>> kwro...@hawkusa.com
>>>
>>>
>>> On 12/13/2012 03:08 PM, Romain Manni-Bucau wrote:

 Question from a none netbeans user: when creating a new JavaEE 6
 project netbeans doesn't create a beans.xml?

 Romain Manni-Bucau
 Twitter: @rmannibucau
 Blog: http://rmannibucau.wordpress.com/
 LinkedIn: http://fr.linkedin.com/in/rmannibucau
 Github: https://github.com/rmannibucau



 2012/12/13 Howard W. Smith, Jr. :
>
> I struggled getting mine to work as well, but I was advised to either
> add
> beans.xml to WEB-INF or META-INF folder.
>
> I learned that in NetBeans, for META-INF, you create a new folder in
> the
> same folder that contain all your java code. Netbeans does not like
> META-INF/beans.xml, you get squiggly lines etc when trying to code, so
> the
> full path of mine is as follows:
>
> C:\Users\Public\NetBeansProjects\mcms_tomee\web\WEB-INF\beans.xml
>
> Empty beans.xml would be like the following:
>
>
> 
> http://java.sun.com/xml/ns/javaee";
>  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
>  xsi:schemaLocation="http://java.sun.com/xml/ns/javaee
> http://java.sun.com/xml/ns/javaee/beans_1_0.xsd";>
> 
>
>
>
>
> On Thu, Dec 13, 2012 at 3:56 PM, Kay Wrobel 
> wrote:
>
>> Now CDI is item number one in the feature list of TomEE Web Profile
>> and
>> has been since version 1.0 if I remember correctly. I just can't get
>> it
>> to
>> work...
>>>
>>>
>>>
>>> --
>>>
>>> --
>>> The information in this e-mail is confidential and is intended solely for
>>> the addressee(s). Access to this email by anyone else is unauthorized. If
>>> you are not an intended recipient, you may not print, save or otherwise
>>> store the e-mail or any of the contents thereof in electronic or physical
>>> form, nor copy, use or disseminate the information contained in the
>>> email.
>>> If you are not an intended recipient,  please notify the sender of this
>>> email immediately.
>
>
>
> --
>
> --
> The information in this e-mail is confidential and is intended solely for
> the addressee(s). Access to this email by anyone else is unauthorized. If
> you are not an intended recipient, you may not print, save or otherwise
> store the e-mail or any of the contents thereof in electronic or physical
> form, nor copy, use or disseminate the information contained in the email.
> If you are not an intended recipient,  please notify the sender of this
> email immediately.

Re: Simple Netbeans CDI Web Application Not Working

[Kay Wrobel]

Hey, that's good. I take it you're an Eclipse user then? I really want 
to like Eclipse, but I find there are just too many things where I have 
to lay my hands on that would work out of the box with Netbeans. At the 
same time, Netbeans currentlt doesn't let me generate JSF pages from 
Entity Beans if the server is not a full Java EE server, and it just 
doesn't recognize TomEE as one. That's I think handled better in 
Eclipse. So yeah, I'm like inbetween because I'm new to Java EE 
development. I come from Visual Studio .NET 2010 and, well, it is mighty 
refined let me tell you. But we're investigating getting away from that 
to a more open platform-independent solution. And Java EE fits really 
well. Plus Primefaces... it's sweet sweet sweet.


Kay

On 12/13/2012 03:15 PM, Romain Manni-Bucau wrote:

you'll not get issue with your management, the 1.5.1 release passed,
we just wait Jean-Louis to push binaries on repo1 :)

Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
LinkedIn: http://fr.linkedin.com/in/rmannibucau
Github: https://github.com/rmannibucau



2012/12/13 Kay Wrobel :

It does when you check the "Enable Context and Dependency Injection" check
box.


  Kay Wrobel

MIS Associate
*Hawk Electronics, Inc.*
800-THE-HAWK
800-843-4295
kwro...@hawkusa.com


On 12/13/2012 03:08 PM, Romain Manni-Bucau wrote:

Question from a none netbeans user: when creating a new JavaEE 6
project netbeans doesn't create a beans.xml?

Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
LinkedIn: http://fr.linkedin.com/in/rmannibucau
Github: https://github.com/rmannibucau



2012/12/13 Howard W. Smith, Jr. :

I struggled getting mine to work as well, but I was advised to either add
beans.xml to WEB-INF or META-INF folder.

I learned that in NetBeans, for META-INF, you create a new folder in the
same folder that contain all your java code. Netbeans does not like
META-INF/beans.xml, you get squiggly lines etc when trying to code, so
the
full path of mine is as follows:

C:\Users\Public\NetBeansProjects\mcms_tomee\web\WEB-INF\beans.xml

Empty beans.xml would be like the following:



http://java.sun.com/xml/ns/javaee";
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
 xsi:schemaLocation="http://java.sun.com/xml/ns/javaee
http://java.sun.com/xml/ns/javaee/beans_1_0.xsd";>





On Thu, Dec 13, 2012 at 3:56 PM, Kay Wrobel  wrote:


Now CDI is item number one in the feature list of TomEE Web Profile and
has been since version 1.0 if I remember correctly. I just can't get it
to
work...



--

--
The information in this e-mail is confidential and is intended solely for
the addressee(s). Access to this email by anyone else is unauthorized. If
you are not an intended recipient, you may not print, save or otherwise
store the e-mail or any of the contents thereof in electronic or physical
form, nor copy, use or disseminate the information contained in the email.
If you are not an intended recipient,  please notify the sender of this
email immediately.



--

--
The information in this e-mail is confidential and is intended solely for 
the addressee(s). Access to this email by anyone else is unauthorized. If 
you are not an intended recipient, you may not print, save or otherwise 
store the e-mail or any of the contents thereof in electronic or physical 
form, nor copy, use or disseminate the information contained in the email. 
If you are not an intended recipient,  please notify the sender of this 
email immediately.

Re: Why are Tomcat's threads more costly than background threads?

[Howard W. Smith, Jr.]

David,

1. definitely not using @Asynchronous; that was no good at all

2. Actually, it was 2 seconds on the Windows Server 2008 64-bit 16GB RAM...
always

3. Always 5 to 10 minutes to process 1 or 2 emails on Windows Server 2003
32-bit 4GB RAM

4. As noted on the JIRA, I tried the TransactionAttribute NEVER and
REQUIRES_NEW on @Stateless EJB that was all invoked via @Schedule, and same
test results, which are The EJB timer rolls back the transaction, and
every database operation that the EmailStatelessBean completed...prior to
@Schedule rolling back the transaction.



On Thu, Dec 13, 2012 at 4:06 PM, David Blevins wrote:

> > David,
> >
> > Yes, please refer to the following (and see what I wrote at the beginning
> > of that comment), thanks.
> >
> > https://issues.apache.org/jira/browse/OPENEJB-1968#comment-13531442
> >
>
> So first note, the @TransactionAttribute(value =
> TransactionAttributeType.NEVER) and @TransactionAttribute(value =
> TransactionAttributeType.REQUIRES_NEW) were two aspects of the same
> suggestion.
>
> Second note is, were I in your shoes, the very first thing I'd do is
> revert all the @ApplicationScoped and @Asychronous stuff and go back to the
> code that only took 2 minutes -- I seem to recall that before it jumped to
> 30 minutes there was a version that ran faster (2 minute range).

Re: Simple Netbeans CDI Web Application Not Working

[Romain Manni-Bucau]

you'll not get issue with your management, the 1.5.1 release passed,
we just wait Jean-Louis to push binaries on repo1 :)

Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
LinkedIn: http://fr.linkedin.com/in/rmannibucau
Github: https://github.com/rmannibucau



2012/12/13 Kay Wrobel :
> It does when you check the "Enable Context and Dependency Injection" check
> box.
>
>
>  Kay Wrobel
>
> MIS Associate
> *Hawk Electronics, Inc.*
> 800-THE-HAWK
> 800-843-4295
> kwro...@hawkusa.com
>
>
> On 12/13/2012 03:08 PM, Romain Manni-Bucau wrote:
>>
>> Question from a none netbeans user: when creating a new JavaEE 6
>> project netbeans doesn't create a beans.xml?
>>
>> Romain Manni-Bucau
>> Twitter: @rmannibucau
>> Blog: http://rmannibucau.wordpress.com/
>> LinkedIn: http://fr.linkedin.com/in/rmannibucau
>> Github: https://github.com/rmannibucau
>>
>>
>>
>> 2012/12/13 Howard W. Smith, Jr. :
>>>
>>> I struggled getting mine to work as well, but I was advised to either add
>>> beans.xml to WEB-INF or META-INF folder.
>>>
>>> I learned that in NetBeans, for META-INF, you create a new folder in the
>>> same folder that contain all your java code. Netbeans does not like
>>> META-INF/beans.xml, you get squiggly lines etc when trying to code, so
>>> the
>>> full path of mine is as follows:
>>>
>>> C:\Users\Public\NetBeansProjects\mcms_tomee\web\WEB-INF\beans.xml
>>>
>>> Empty beans.xml would be like the following:
>>>
>>>
>>> 
>>> http://java.sun.com/xml/ns/javaee";
>>> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
>>> xsi:schemaLocation="http://java.sun.com/xml/ns/javaee
>>> http://java.sun.com/xml/ns/javaee/beans_1_0.xsd";>
>>> 
>>>
>>>
>>>
>>>
>>> On Thu, Dec 13, 2012 at 3:56 PM, Kay Wrobel  wrote:
>>>
 Now CDI is item number one in the feature list of TomEE Web Profile and
 has been since version 1.0 if I remember correctly. I just can't get it
 to
 work...
>
>
>
> --
>
> --
> The information in this e-mail is confidential and is intended solely for
> the addressee(s). Access to this email by anyone else is unauthorized. If
> you are not an intended recipient, you may not print, save or otherwise
> store the e-mail or any of the contents thereof in electronic or physical
> form, nor copy, use or disseminate the information contained in the email.
> If you are not an intended recipient,  please notify the sender of this
> email immediately.

Re: Simple Netbeans CDI Web Application Not Working

[Kay Wrobel]

It does when you check the "Enable Context and Dependency Injection" 
check box.



 Kay Wrobel

MIS Associate
*Hawk Electronics, Inc.*
800-THE-HAWK
800-843-4295
kwro...@hawkusa.com

On 12/13/2012 03:08 PM, Romain Manni-Bucau wrote:

Question from a none netbeans user: when creating a new JavaEE 6
project netbeans doesn't create a beans.xml?

Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
LinkedIn: http://fr.linkedin.com/in/rmannibucau
Github: https://github.com/rmannibucau



2012/12/13 Howard W. Smith, Jr. :

I struggled getting mine to work as well, but I was advised to either add
beans.xml to WEB-INF or META-INF folder.

I learned that in NetBeans, for META-INF, you create a new folder in the
same folder that contain all your java code. Netbeans does not like
META-INF/beans.xml, you get squiggly lines etc when trying to code, so the
full path of mine is as follows:

C:\Users\Public\NetBeansProjects\mcms_tomee\web\WEB-INF\beans.xml

Empty beans.xml would be like the following:



http://java.sun.com/xml/ns/javaee";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xsi:schemaLocation="http://java.sun.com/xml/ns/javaee
http://java.sun.com/xml/ns/javaee/beans_1_0.xsd";>





On Thu, Dec 13, 2012 at 3:56 PM, Kay Wrobel  wrote:


Now CDI is item number one in the feature list of TomEE Web Profile and
has been since version 1.0 if I remember correctly. I just can't get it to
work...



--

--
The information in this e-mail is confidential and is intended solely for 
the addressee(s). Access to this email by anyone else is unauthorized. If 
you are not an intended recipient, you may not print, save or otherwise 
store the e-mail or any of the contents thereof in electronic or physical 
form, nor copy, use or disseminate the information contained in the email. 
If you are not an intended recipient,  please notify the sender of this 
email immediately.

Re: Simple Netbeans CDI Web Application Not Working

[Kay Wrobel]

Romain + Howard:
I completely removed 1.5.0 and downloaded latest 1.5.1 snapshot 
(apache-tomee-1.5.1-20121212.041901-106-plus.tar.gz), extracted it to 
/usr/local/java, started the server and copied the war file to the 
webapps folder. I then opened the app URL again and now I get:

Message is: beans.WelcomeBean@655d267a You called me 3 times
So, yeah. Thanks and that works. But this is a snapshot and not a 
release, so i.d.k. if that's got production stability or not.


Regarding the jars you both mentioned: none of them are in the libs (or 
endorsed) directories except for joda-time-1.6.2.jar.


This leaves me kinda hanging now: I am happy that it works, but I also 
don't know why it didn't work with the official build on TomEE's web 
site. I will have a hard time pitching this to management (not really 
your concern, I know). Just saying: I wish something like this wasn't 
broken out of the box.


Thanks,

Kay

On 12/13/2012 02:55 PM, Romain Manni-Bucau wrote:

well as said by oward first give a try to the last version

then don't move/remove/add these jar before you need it:

asm-3.3.1.jar (added that when I was evaluating batoo jpa)
derby.jar
eclipselink.jar
el-api-2.2
el-impl-2.2
javax.mail
joda-time-2.0 (to replace joda-time-1.6.2 which already exists in tomee/lib)
juel-2.2.5 (since I'm using JUEL with MyFaces for faster/better EL
performance)

(sorry Howard :p)

basically: derby is needed only if you use derby database (never found
a good reason to do so...maybe cause i dont use eclipselink), el stuff
is already here (and doesnt hurt AFAIK so dont modify the server
before needing it), same for eclipselink, if openjpa matches your need
just use it

about your sample, please test it in standalone, if it doesn't work
just share it (if you cant) and well have a look

Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
LinkedIn: http://fr.linkedin.com/in/rmannibucau
Github: https://github.com/rmannibucau



2012/12/13 Kay Wrobel :

@Romain:
Well, the  tag was automatically added by Netbeans when I
created the project. I commented it out when I re-targeted the project to
Glassfish or Glassfish would throw a deploy exception.

So with the project targeted to Glassfish, I clicked in "Clean and Build" on
the Project node and exited out of Netbeans. I then started the TomEE
instance from the command line with bin/startup.sh. Then I cd'ed into
webapps and copied the war file from my dist directory in the Netbeans
project, triggering a deploy as follows:

INFO: Deploying web application archive
/usr/local/java/apache-tomee-plus-1.5.0/webapps/CDITest.war
Dec 13, 2012 2:45:21 PM org.apache.tomee.catalina.TomcatWebAppBuilder init
INFO: -
TomcatWebAppBuilder.init /CDITest
Dec 13, 2012 2:45:21 PM org.apache.openejb.util.JarExtractor extract
INFO: Extracting jar:
/usr/local/java/apache-tomee-plus-1.5.0/webapps/CDITest.war
Dec 13, 2012 2:45:21 PM org.apache.openejb.util.JarExtractor extract
INFO: Extracted path:
/usr/local/java/apache-tomee-plus-1.5.0/webapps/CDITest
Dec 13, 2012 2:45:22 PM org.apache.openejb.config.ConfigurationFactory
configureApplication
INFO: Configuring enterprise application:
/usr/local/java/apache-tomee-plus-1.5.0/webapps/CDITest
Dec 13, 2012 2:45:22 PM org.apache.openejb.config.AppInfoBuilder build
INFO: Enterprise application
"/usr/local/java/apache-tomee-plus-1.5.0/webapps/CDITest" loaded.
Dec 13, 2012 2:45:22 PM org.apache.openejb.assembler.classic.Assembler
createApplication
INFO: Assembling app:
/usr/local/java/apache-tomee-plus-1.5.0/webapps/CDITest
Dec 13, 2012 2:45:22 PM org.apache.openejb.cdi.CdiBuilder initSingleton
INFO: Existing thread singleton service in SystemInstance()
org.apache.openejb.cdi.ThreadSingletonServiceImpl@3083e8d
Dec 13, 2012 2:45:22 PM org.apache.openejb.cdi.OpenEJBLifecycle
startApplication
INFO: OpenWebBeans Container is starting...
Dec 13, 2012 2:45:22 PM org.apache.webbeans.plugins.PluginLoader startUp
INFO: Adding OpenWebBeansPlugin : [CdiPlugin]
Dec 13, 2012 2:45:22 PM org.apache.webbeans.plugins.PluginLoader startUp
INFO: Adding OpenWebBeansPlugin : [OpenWebBeansJsfPlugin]
Dec 13, 2012 2:45:22 PM org.apache.openejb.cdi.BeansDeployer
validateInjectionPoints
INFO: All injection points are validated successfully.
Dec 13, 2012 2:45:22 PM org.apache.openejb.cdi.OpenEJBLifecycle
startApplication
INFO: OpenWebBeans Container has started, it took 6 ms.
Dec 13, 2012 2:45:22 PM org.apache.tomee.catalina.TomcatWebAppBuilder
deployWebApps
INFO: using context file
/usr/local/java/apache-tomee-plus-1.5.0/webapps/CDITest/META-INF/context.xml
Dec 13, 2012 2:45:22 PM org.apache.openejb.assembler.classic.Assembler
createApplication
INFO: Deployed
Application(path=/usr/local/java/apache-tomee-plus-1.5.0/webapps/CDITest)
Dec 13, 2012 2:45:22 PM
org.apache.myfaces.config.DefaultFacesConfigurationProvider
getStandardFacesConfig
INFO: Reading standard config META-INF/standard-faces-config.xml
Dec 13, 2012 2:45:22 PM org.apac

Re: Simple Netbeans CDI Web Application Not Working

[Romain Manni-Bucau]

Question from a none netbeans user: when creating a new JavaEE 6
project netbeans doesn't create a beans.xml?

Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
LinkedIn: http://fr.linkedin.com/in/rmannibucau
Github: https://github.com/rmannibucau



2012/12/13 Howard W. Smith, Jr. :
> I struggled getting mine to work as well, but I was advised to either add
> beans.xml to WEB-INF or META-INF folder.
>
> I learned that in NetBeans, for META-INF, you create a new folder in the
> same folder that contain all your java code. Netbeans does not like
> META-INF/beans.xml, you get squiggly lines etc when trying to code, so the
> full path of mine is as follows:
>
> C:\Users\Public\NetBeansProjects\mcms_tomee\web\WEB-INF\beans.xml
>
> Empty beans.xml would be like the following:
>
>
> 
> http://java.sun.com/xml/ns/javaee";
>xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
>xsi:schemaLocation="http://java.sun.com/xml/ns/javaee
> http://java.sun.com/xml/ns/javaee/beans_1_0.xsd";>
> 
>
>
>
>
> On Thu, Dec 13, 2012 at 3:56 PM, Kay Wrobel  wrote:
>
>> Now CDI is item number one in the feature list of TomEE Web Profile and
>> has been since version 1.0 if I remember correctly. I just can't get it to
>> work...

Re: Simple Netbeans CDI Web Application Not Working

[Howard W. Smith, Jr.]

I struggled getting mine to work as well, but I was advised to either add
beans.xml to WEB-INF or META-INF folder.

I learned that in NetBeans, for META-INF, you create a new folder in the
same folder that contain all your java code. Netbeans does not like
META-INF/beans.xml, you get squiggly lines etc when trying to code, so the
full path of mine is as follows:

C:\Users\Public\NetBeansProjects\mcms_tomee\web\WEB-INF\beans.xml

Empty beans.xml would be like the following:



http://java.sun.com/xml/ns/javaee";
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
   xsi:schemaLocation="http://java.sun.com/xml/ns/javaee
http://java.sun.com/xml/ns/javaee/beans_1_0.xsd";>





On Thu, Dec 13, 2012 at 3:56 PM, Kay Wrobel  wrote:

> Now CDI is item number one in the feature list of TomEE Web Profile and
> has been since version 1.0 if I remember correctly. I just can't get it to
> work...

Re: Why are Tomcat's threads more costly than background threads?

[David Blevins]

On Dec 13, 2012, at 12:27 PM, "Howard W. Smith, Jr."  
wrote:

> David,
> 
> Yes, please refer to the following (and see what I wrote at the beginning
> of that comment), thanks.
> 
> https://issues.apache.org/jira/browse/OPENEJB-1968#comment-13531442
> 

So first note, the @TransactionAttribute(value = 
TransactionAttributeType.NEVER) and @TransactionAttribute(value = 
TransactionAttributeType.REQUIRES_NEW) were two aspects of the same suggestion.

Second note is, were I in your shoes, the very first thing I'd do is revert all 
the @ApplicationScoped and @Asychronous stuff and go back to the code that only 
took 2 minutes -- I seem to recall that before it jumped to 30 minutes there 
was a version that ran faster (2 minute range).

Third, all versions of the code posted have the same flaw as the original code 
-- there is only one transaction for processing all emails.  This is the 
fundamental problem and there is no possible solution that involves *adding* 
code and not changing this one fundamental flaw.  This is why when you added 
the code that waited for a safe time to do the processing it made things worse 
-- it was too late a transaction was already started and the database tables 
already locked.

We can definitely get this working better, but the problem is there is simply 
too much code happing in one transaction.  No other fix will help.

If you're willing to go back to the original version of the code and do *only* 
the suggestions given, I think we can get this easily sorted out today.

Thoughts?


-David

Re: Simple Netbeans CDI Web Application Not Working

[Kay Wrobel]

Thanks, Howard.

For this simple example, I don't need to set up and Resources just yet. 
I've seen the documentation pages regarding the topics you mentioned and 
am aware of them. This is just too simple of an example, and it's 
failing miserably right now.


You see, I am evaluating Java EE as a whole right now because I'm 
pitching a completely rewrite of a bigger project currently written in 
.NET to upper management. And as much as I like the reference 
implementation of Glassfish, I'd like to explore TomEE as well. I like 
the idea of it all being licensed under the Apache License.


Now CDI is item number one in the feature list of TomEE Web Profile and 
has been since version 1.0 if I remember correctly. I just can't get it 
to work...


Kay

On 12/13/2012 02:43 PM, Howard W. Smith, Jr. wrote:

Kay,

Welcome to TomEE, and glad to see someone that is interested in doing what
I did at least one month ago.

Please note/do the following:

1. Download TomEE Plus 1.5.1 (SNAPSHOT) instead of 1.5.0; 1.5.0 did not
work at all for me as my environment is Windows Server 2003 & 2008; 1.5.1
resolves a file/directory/path issue in TomEE.

2. tomEE 1.5.1 comes bundled with MyFaces 2.1.10 (few weeks ago, it was
bundled with MyFaces 2.1.9), and I never had the following 'reference' in
my web.xml; I think I heard/read that you don't need the following i/fsince
you are using servlet 3.0 in web.xml

 
org.apache.**myfaces.webapp.**StartupServletContextListener<
**/listener-class>
 

3. Copy any/all dependencies to your tomee/lib folder; whenever I install a
new SNAPSHOT version of TomEE 1.5.1, I copy the following to tomee /lib

asm-3.3.1.jar (added that when I was evaluating batoo jpa)
derby.jar
eclipselink.jar
el-api-2.2
el-impl-2.2
javax.mail
joda-time-2.0 (to replace joda-time-1.6.2 which already exists in tomee/lib)
juel-2.2.5 (since I'm using JUEL with MyFaces for faster/better EL
performance)

4. take a look at tomee/conf/tomee.xml; at the bottom of that file, you
will see JDBC resources defined there; put your JDBC resources there

5. your persistence.xml, make sure you set your persistence provider, or
TomEE will default it to OpenJPA; i use eclipselink (since Glassfish3.1.2.2
used eclipselink, by default, and my app performs really well with
eclipselink)

6. also, see tomee/conf/tomcat-users.xml; read all the lines below
(copy/pasted from my file), especially the last line...for Netbeans. :)





   



Hope this helps,
Howard



On Thu, Dec 13, 2012 at 3:12 PM, Kay Wrobel  wrote:


Hi everybody.

I am new to TomEE and am having problems with the very basics of getting a
simple CDI Application to work from Netbeans 7.2. I have added TomEE Plus
1.5.0 as a server via the Tools->Servers->Add Server... steps. The problem
I have is as follows:

I create a simple Web Application with Context and Dependency Injection
enabled and server-supplied JSF 2.1 implementation activated. I proceed to
adding a very simple WelcomeBean.java file that looks like this:


package beans;

import java.io.Serializable;
import javax.enterprise.context.**SessionScoped;
import javax.inject.Named;

/**
  *
  * @author kuw
  */
@Named(value = "welcomeBean")
@SessionScoped
public class WelcomeBean implements Serializable {

 private int counter;

 /**
  * Creates a new instance of WelcomeBean
  */
 public WelcomeBean() {
 }

 public String getMessage() {
 return super.toString() + String.format(" You called me %d
times", ++counter);
 }
}


and then access that bean from the index.xhtml page like this:



 
 Message is: 
 
 


When I run the project, the page simply shows this: "Message is:" and the
nothing. I can't see anything in the project files that is missing. I have
the empty shell of beans.xml file to enable CDI, web.xml is fairly standard
only that I changed the url-pattern for the Faces Servlet. Here's the
complete web.xml:



http://java.sun.com/**xml/ns/javaee"
xmlns:xsi="http://www.w3.org/**2001/XMLSchema-instance"
xsi:schemaLocation="http://**java.sun.com/xml/ns/javaee
http://java.sun.com/xml/ns/**javaee/web-app_3_0.xsd
">
 
javax.faces.**PROJECT_STAGE
 Development
 
 
org.apache.**myfaces.webapp.**
StartupServletContextListener<**/listener-class>
 
 
 Faces Servlet
javax.faces.**webapp.FacesServlet
 1
 
 
 Faces Servlet
 *.xhtml
 
 
 
 30
 
 
 
 index.xhtml
 



So my question now is: what is going on? I don't see any obvious error
messages in the different Output tabs in Netbeans.

Btw. If I target the project to the Glassfish server, it works as expected:


Message is: beans.WelcomeBean@77431c1f You called me 3 times


(after reloading page two times).

Anyone 

Re: Simple Netbeans CDI Web Application Not Working

[Romain Manni-Bucau]

well as said by oward first give a try to the last version

then don't move/remove/add these jar before you need it:

asm-3.3.1.jar (added that when I was evaluating batoo jpa)
derby.jar
eclipselink.jar
el-api-2.2
el-impl-2.2
javax.mail
joda-time-2.0 (to replace joda-time-1.6.2 which already exists in tomee/lib)
juel-2.2.5 (since I'm using JUEL with MyFaces for faster/better EL
performance)

(sorry Howard :p)

basically: derby is needed only if you use derby database (never found
a good reason to do so...maybe cause i dont use eclipselink), el stuff
is already here (and doesnt hurt AFAIK so dont modify the server
before needing it), same for eclipselink, if openjpa matches your need
just use it

about your sample, please test it in standalone, if it doesn't work
just share it (if you cant) and well have a look

Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
LinkedIn: http://fr.linkedin.com/in/rmannibucau
Github: https://github.com/rmannibucau



2012/12/13 Kay Wrobel :
> @Romain:
> Well, the  tag was automatically added by Netbeans when I
> created the project. I commented it out when I re-targeted the project to
> Glassfish or Glassfish would throw a deploy exception.
>
> So with the project targeted to Glassfish, I clicked in "Clean and Build" on
> the Project node and exited out of Netbeans. I then started the TomEE
> instance from the command line with bin/startup.sh. Then I cd'ed into
> webapps and copied the war file from my dist directory in the Netbeans
> project, triggering a deploy as follows:
>>
>> INFO: Deploying web application archive
>> /usr/local/java/apache-tomee-plus-1.5.0/webapps/CDITest.war
>> Dec 13, 2012 2:45:21 PM org.apache.tomee.catalina.TomcatWebAppBuilder init
>> INFO: -
>> TomcatWebAppBuilder.init /CDITest
>> Dec 13, 2012 2:45:21 PM org.apache.openejb.util.JarExtractor extract
>> INFO: Extracting jar:
>> /usr/local/java/apache-tomee-plus-1.5.0/webapps/CDITest.war
>> Dec 13, 2012 2:45:21 PM org.apache.openejb.util.JarExtractor extract
>> INFO: Extracted path:
>> /usr/local/java/apache-tomee-plus-1.5.0/webapps/CDITest
>> Dec 13, 2012 2:45:22 PM org.apache.openejb.config.ConfigurationFactory
>> configureApplication
>> INFO: Configuring enterprise application:
>> /usr/local/java/apache-tomee-plus-1.5.0/webapps/CDITest
>> Dec 13, 2012 2:45:22 PM org.apache.openejb.config.AppInfoBuilder build
>> INFO: Enterprise application
>> "/usr/local/java/apache-tomee-plus-1.5.0/webapps/CDITest" loaded.
>> Dec 13, 2012 2:45:22 PM org.apache.openejb.assembler.classic.Assembler
>> createApplication
>> INFO: Assembling app:
>> /usr/local/java/apache-tomee-plus-1.5.0/webapps/CDITest
>> Dec 13, 2012 2:45:22 PM org.apache.openejb.cdi.CdiBuilder initSingleton
>> INFO: Existing thread singleton service in SystemInstance()
>> org.apache.openejb.cdi.ThreadSingletonServiceImpl@3083e8d
>> Dec 13, 2012 2:45:22 PM org.apache.openejb.cdi.OpenEJBLifecycle
>> startApplication
>> INFO: OpenWebBeans Container is starting...
>> Dec 13, 2012 2:45:22 PM org.apache.webbeans.plugins.PluginLoader startUp
>> INFO: Adding OpenWebBeansPlugin : [CdiPlugin]
>> Dec 13, 2012 2:45:22 PM org.apache.webbeans.plugins.PluginLoader startUp
>> INFO: Adding OpenWebBeansPlugin : [OpenWebBeansJsfPlugin]
>> Dec 13, 2012 2:45:22 PM org.apache.openejb.cdi.BeansDeployer
>> validateInjectionPoints
>> INFO: All injection points are validated successfully.
>> Dec 13, 2012 2:45:22 PM org.apache.openejb.cdi.OpenEJBLifecycle
>> startApplication
>> INFO: OpenWebBeans Container has started, it took 6 ms.
>> Dec 13, 2012 2:45:22 PM org.apache.tomee.catalina.TomcatWebAppBuilder
>> deployWebApps
>> INFO: using context file
>> /usr/local/java/apache-tomee-plus-1.5.0/webapps/CDITest/META-INF/context.xml
>> Dec 13, 2012 2:45:22 PM org.apache.openejb.assembler.classic.Assembler
>> createApplication
>> INFO: Deployed
>> Application(path=/usr/local/java/apache-tomee-plus-1.5.0/webapps/CDITest)
>> Dec 13, 2012 2:45:22 PM
>> org.apache.myfaces.config.DefaultFacesConfigurationProvider
>> getStandardFacesConfig
>> INFO: Reading standard config META-INF/standard-faces-config.xml
>> Dec 13, 2012 2:45:22 PM org.apache.myfaces.config.LogMetaInfUtils
>> logArtifact
>> INFO: Artifact 'myfaces-api' was found in version '2.1.9' from path
>> 'file:/usr/local/java/apache-tomee-plus-1.5.0/lib/myfaces-api-2.1.9.jar'
>> Dec 13, 2012 2:45:22 PM org.apache.myfaces.config.LogMetaInfUtils
>> logArtifact
>> INFO: Artifact 'myfaces-impl' was found in version '2.1.9' from path
>> 'file:/usr/local/java/apache-tomee-plus-1.5.0/lib/myfaces-impl-2.1.9.jar'
>> Dec 13, 2012 2:45:22 PM org.apache.myfaces.config.FacesConfigurator
>> handleSerialFactory
>> INFO: Serialization provider : class
>> org.apache.myfaces.shared_impl.util.serial.DefaultSerialFactory
>> Dec 13, 2012 2:45:22 PM
>> org.apache.myfaces.config.annotation.DefaultLifecycleProviderFactory
>> getLifecycleProvider
>> INFO: Using LifecycleProvider
>> org.apache.myfaces.

Re: Simple Netbeans CDI Web Application Not Working

[Kay Wrobel]

@Romain:
Well, the  tag was automatically added by Netbeans when 
I created the project. I commented it out when I re-targeted the project 
to Glassfish or Glassfish would throw a deploy exception.


So with the project targeted to Glassfish, I clicked in "Clean and 
Build" on the Project node and exited out of Netbeans. I then started 
the TomEE instance from the command line with bin/startup.sh. Then I 
cd'ed into webapps and copied the war file from my dist directory in the 
Netbeans project, triggering a deploy as follows:
INFO: Deploying web application archive 
/usr/local/java/apache-tomee-plus-1.5.0/webapps/CDITest.war

Dec 13, 2012 2:45:21 PM org.apache.tomee.catalina.TomcatWebAppBuilder init
INFO: -
TomcatWebAppBuilder.init /CDITest
Dec 13, 2012 2:45:21 PM org.apache.openejb.util.JarExtractor extract
INFO: Extracting jar: 
/usr/local/java/apache-tomee-plus-1.5.0/webapps/CDITest.war

Dec 13, 2012 2:45:21 PM org.apache.openejb.util.JarExtractor extract
INFO: Extracted path: 
/usr/local/java/apache-tomee-plus-1.5.0/webapps/CDITest
Dec 13, 2012 2:45:22 PM org.apache.openejb.config.ConfigurationFactory 
configureApplication
INFO: Configuring enterprise application: 
/usr/local/java/apache-tomee-plus-1.5.0/webapps/CDITest

Dec 13, 2012 2:45:22 PM org.apache.openejb.config.AppInfoBuilder build
INFO: Enterprise application 
"/usr/local/java/apache-tomee-plus-1.5.0/webapps/CDITest" loaded.
Dec 13, 2012 2:45:22 PM org.apache.openejb.assembler.classic.Assembler 
createApplication
INFO: Assembling app: 
/usr/local/java/apache-tomee-plus-1.5.0/webapps/CDITest

Dec 13, 2012 2:45:22 PM org.apache.openejb.cdi.CdiBuilder initSingleton
INFO: Existing thread singleton service in SystemInstance() 
org.apache.openejb.cdi.ThreadSingletonServiceImpl@3083e8d
Dec 13, 2012 2:45:22 PM org.apache.openejb.cdi.OpenEJBLifecycle 
startApplication

INFO: OpenWebBeans Container is starting...
Dec 13, 2012 2:45:22 PM org.apache.webbeans.plugins.PluginLoader startUp
INFO: Adding OpenWebBeansPlugin : [CdiPlugin]
Dec 13, 2012 2:45:22 PM org.apache.webbeans.plugins.PluginLoader startUp
INFO: Adding OpenWebBeansPlugin : [OpenWebBeansJsfPlugin]
Dec 13, 2012 2:45:22 PM org.apache.openejb.cdi.BeansDeployer 
validateInjectionPoints

INFO: All injection points are validated successfully.
Dec 13, 2012 2:45:22 PM org.apache.openejb.cdi.OpenEJBLifecycle 
startApplication

INFO: OpenWebBeans Container has started, it took 6 ms.
Dec 13, 2012 2:45:22 PM org.apache.tomee.catalina.TomcatWebAppBuilder 
deployWebApps
INFO: using context file 
/usr/local/java/apache-tomee-plus-1.5.0/webapps/CDITest/META-INF/context.xml
Dec 13, 2012 2:45:22 PM org.apache.openejb.assembler.classic.Assembler 
createApplication
INFO: Deployed 
Application(path=/usr/local/java/apache-tomee-plus-1.5.0/webapps/CDITest)
Dec 13, 2012 2:45:22 PM 
org.apache.myfaces.config.DefaultFacesConfigurationProvider 
getStandardFacesConfig

INFO: Reading standard config META-INF/standard-faces-config.xml
Dec 13, 2012 2:45:22 PM org.apache.myfaces.config.LogMetaInfUtils 
logArtifact
INFO: Artifact 'myfaces-api' was found in version '2.1.9' from path 
'file:/usr/local/java/apache-tomee-plus-1.5.0/lib/myfaces-api-2.1.9.jar'
Dec 13, 2012 2:45:22 PM org.apache.myfaces.config.LogMetaInfUtils 
logArtifact
INFO: Artifact 'myfaces-impl' was found in version '2.1.9' from path 
'file:/usr/local/java/apache-tomee-plus-1.5.0/lib/myfaces-impl-2.1.9.jar'
Dec 13, 2012 2:45:22 PM org.apache.myfaces.config.FacesConfigurator 
handleSerialFactory
INFO: Serialization provider : class 
org.apache.myfaces.shared_impl.util.serial.DefaultSerialFactory
Dec 13, 2012 2:45:22 PM 
org.apache.myfaces.config.annotation.DefaultLifecycleProviderFactory 
getLifecycleProvider
INFO: Using LifecycleProvider 
org.apache.myfaces.config.annotation.Tomcat7AnnotationLifecycleProvider
Dec 13, 2012 2:45:22 PM 
org.apache.myfaces.webapp.AbstractFacesInitializer initFaces

INFO: ServletContext initialized.
Dec 13, 2012 2:45:22 PM 
org.apache.myfaces.webapp.AbstractFacesInitializer initFaces

WARNING:

***
*** WARNING: Apache MyFaces-2 is running in DEVELOPMENT mode. ***
*** ^^^ ***
*** Do NOT deploy to your live server(s) without changing this. ***
*** See Application#getProjectStage() for more information. ***
***

I go the the app URL ( http://localhost:8080/CDITest/) and still get 
nothing other than the hard-coded text, not the text from the bean method.


So, yeah, I guess the  tag was not necessary. Actually 
makes it easier for me to switch between Glassfish and TomEE in 
Netbeans. Anyway, do you have other suggestions?


Thanks,

Kay

On 12/13/2012 02:37 PM, Romain Manni-Bucau wrote:

hmm,

org.apache.myfaces.webapp.StartupServletContextListener
is useless but that's not it

did yuo put a beans.xml?

does it work in manual mode (p

Re: Simple Netbeans CDI Web Application Not Working

[Howard W. Smith, Jr.]

Kay,

Welcome to TomEE, and glad to see someone that is interested in doing what
I did at least one month ago.

Please note/do the following:

1. Download TomEE Plus 1.5.1 (SNAPSHOT) instead of 1.5.0; 1.5.0 did not
work at all for me as my environment is Windows Server 2003 & 2008; 1.5.1
resolves a file/directory/path issue in TomEE.

2. tomEE 1.5.1 comes bundled with MyFaces 2.1.10 (few weeks ago, it was
bundled with MyFaces 2.1.9), and I never had the following 'reference' in
my web.xml; I think I heard/read that you don't need the following i/fsince
you are using servlet 3.0 in web.xml


org.apache.**myfaces.webapp.**StartupServletContextListener<
**/listener-class>


3. Copy any/all dependencies to your tomee/lib folder; whenever I install a
new SNAPSHOT version of TomEE 1.5.1, I copy the following to tomee /lib

asm-3.3.1.jar (added that when I was evaluating batoo jpa)
derby.jar
eclipselink.jar
el-api-2.2
el-impl-2.2
javax.mail
joda-time-2.0 (to replace joda-time-1.6.2 which already exists in tomee/lib)
juel-2.2.5 (since I'm using JUEL with MyFaces for faster/better EL
performance)

4. take a look at tomee/conf/tomee.xml; at the bottom of that file, you
will see JDBC resources defined there; put your JDBC resources there

5. your persistence.xml, make sure you set your persistence provider, or
TomEE will default it to OpenJPA; i use eclipselink (since Glassfish3.1.2.2
used eclipselink, by default, and my app performs really well with
eclipselink)

6. also, see tomee/conf/tomcat-users.xml; read all the lines below
(copy/pasted from my file), especially the last line...for Netbeans. :)





  



Hope this helps,
Howard



On Thu, Dec 13, 2012 at 3:12 PM, Kay Wrobel  wrote:

> Hi everybody.
>
> I am new to TomEE and am having problems with the very basics of getting a
> simple CDI Application to work from Netbeans 7.2. I have added TomEE Plus
> 1.5.0 as a server via the Tools->Servers->Add Server... steps. The problem
> I have is as follows:
>
> I create a simple Web Application with Context and Dependency Injection
> enabled and server-supplied JSF 2.1 implementation activated. I proceed to
> adding a very simple WelcomeBean.java file that looks like this:
>
>> package beans;
>>
>> import java.io.Serializable;
>> import javax.enterprise.context.**SessionScoped;
>> import javax.inject.Named;
>>
>> /**
>>  *
>>  * @author kuw
>>  */
>> @Named(value = "welcomeBean")
>> @SessionScoped
>> public class WelcomeBean implements Serializable {
>>
>> private int counter;
>>
>> /**
>>  * Creates a new instance of WelcomeBean
>>  */
>> public WelcomeBean() {
>> }
>>
>> public String getMessage() {
>> return super.toString() + String.format(" You called me %d
>> times", ++counter);
>> }
>> }
>>
> and then access that bean from the index.xhtml page like this:
>
>> 
>> 
>> Message is: 
>> 
>> 
>>
> When I run the project, the page simply shows this: "Message is:" and the
> nothing. I can't see anything in the project files that is missing. I have
> the empty shell of beans.xml file to enable CDI, web.xml is fairly standard
> only that I changed the url-pattern for the Faces Servlet. Here's the
> complete web.xml:
>
>> 
>> > xmlns="http://java.sun.com/**xml/ns/javaee"
>> xmlns:xsi="http://www.w3.org/**2001/XMLSchema-instance"
>> xsi:schemaLocation="http://**java.sun.com/xml/ns/javaee
>> http://java.sun.com/xml/ns/**javaee/web-app_3_0.xsd
>> ">
>> 
>> javax.faces.**PROJECT_STAGE
>> Development
>> 
>> 
>> org.apache.**myfaces.webapp.**
>> StartupServletContextListener<**/listener-class>
>> 
>> 
>> Faces Servlet
>> javax.faces.**webapp.FacesServlet
>> 1
>> 
>> 
>> Faces Servlet
>> *.xhtml
>> 
>> 
>> 
>> 30
>> 
>> 
>> 
>> index.xhtml
>> 
>> 
>>
>
> So my question now is: what is going on? I don't see any obvious error
> messages in the different Output tabs in Netbeans.
>
> Btw. If I target the project to the Glassfish server, it works as expected:
>
>> Message is: beans.WelcomeBean@77431c1f You called me 3 times
>>
> (after reloading page two times).
>
> Anyone here have any idea what I am missing? It has to be something
> essential.
>
> Thanks,
>
> Kay
>
>
> --
>
> --
> The information in this e-mail is confidential and is intended solely for
> the addressee(s). Access to this email by anyone else is unauthorized. If
> you are not an intended recipient, you may not print, save or otherwise
> store the e-mail or any of the contents thereof in electronic or physical
> form, nor copy, use or disseminate the information contained in the email.
> If you are not an intended recipient,  please notify the sender of this
> email immediately

Re: openejb.xml

[Romain Manni-Bucau]

hmm jndi.properties is not managed by openejb directly in your case
byt InitialContext IIRC

why not simply passing these properties to openejb when starting the container?

Note: "new" EJBContainer API ignores jndi.properties IIRC

for the datasource you can create a conf folder (in ".") and add
openejb.xml file. For hibernate you'll need to add it somewhere else
(you can use altdd to define a test.persistence.xml normally)

Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
LinkedIn: http://fr.linkedin.com/in/rmannibucau
Github: https://github.com/rmannibucau



2012/12/13 Neale :
> Hi Trevor,
>
> Can you tell us your changes/findings so we can adjust the docs to make it
> easier for everyone else?
>
> Best Regards,
> Neale
>
>
>
> - Original Message - From: "Baker, Trevor" 
> To: 
> Sent: Friday, December 14, 2012 7:10 AM
> Subject: RE: openejb.xml
>
>
>
> Fixed some line-ending weirdness.
>
> -Original Message-
> From: Baker, Trevor [mailto:crba...@mail.ubc.ca]
> Sent: Thursday, December 13, 2012 12:07 PM
> To: users@openejb.apache.org
> Subject: openejb.xml
>
> Hi,
>
> I have the following jndi.properties:
>
> 
> java.naming.factory.initial=org.apache.openejb.client.LocalInitialContextFactory
>
> # create a new data source at: java:/openejb/Resource/dbUnitDS
> dbUnitDS=new://Resource?type=DataSource
> dbUnitDS.JdbcUrl=jdbc:h2:mem:arquillian;DB_CLOSE_DELAY=-1
> dbUnitDS.JdbcDriver=org.h2.Driver
> dbUnitDS.JtaManaged=true
>
> # add properties for the persistence unit
> test.hibernate.dialect=org.hibernate.dialect.H2Dialect
> test.hibernate.hbm2ddl.auto=create-drop
> test.hibernate.id.new_generator_mappings=true
> ---
>
> Unfortunately, jndi.properties is interfering with non-openejb unit tests in
> the project. Would like to convert to openejb.xml but need some help. Can
> someone send back the openejb.xml equivalent. I'm assuming I can place in
> src/test/resources/openejb.xml.
>
> Not being lazy. Just can't find any good resources. Would be nice if this
> page could have a sample openejb.xml:
> http://tomee.apache.org/embedded-configuration.html
>
> Thanks,
> Trev

Re: Simple Netbeans CDI Web Application Not Working

[Romain Manni-Bucau]

hmm,

org.apache.myfaces.webapp.StartupServletContextListener
is useless but that's not it

did yuo put a beans.xml?

does it work in manual mode (put your war in webapps then bin/catalina.sh run)?

Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
LinkedIn: http://fr.linkedin.com/in/rmannibucau
Github: https://github.com/rmannibucau



2012/12/13 Kay Wrobel :
>>
>> org.apache.myfaces.webapp.StartupServletContextListener

Re: DB access is very slow

[Romain Manni-Bucau]

profile just this part :p (without front etc)

Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
LinkedIn: http://fr.linkedin.com/in/rmannibucau
Github: https://github.com/rmannibucau



2012/12/13 Howard W. Smith, Jr. :
> Sorry, don't understand what you're trying to say here.
>
> @Schedule is used to poll or check an email server for 'specific' emails,
> and the emails of interest has JSON embedded, and that JSON are populated
> into POJOs via Gson, and then the fun begins... saving that little bit of
> data to multiple tables... so endusers don't have to perform 'data entry'
> and enter that data 'manually'.
>
> 1. The design and implemenation... works as designed
>
> 2. the @Stateless EJB with @Schedule getEmails().. works as designed
>
> 3. @Stateless EJB (DAO) updating the database.. works as designed but takes
> t long.
>
> You all say it is because of the database, but I actually disagree it is
> the database, because user click button, CDI-managed-bean updating database
> via @Stateless EJB (DAO) is much much faster than #3 listed above.
>
>
> On Thu, Dec 13, 2012 at 2:37 PM, Romain Manni-Bucau
> wrote:
>
>> well your @Schedule == polling no server, it sounds weird by design

Re: Why are Tomcat's threads more costly than background threads?

[Howard W. Smith, Jr.]

David,

Yes, please refer to the following (and see what I wrote at the beginning
of that comment), thanks.

https://issues.apache.org/jira/browse/OPENEJB-1968#comment-13531442


On Thu, Dec 13, 2012 at 3:11 PM, David Blevins wrote:

> The description of EmailStatelessBean still looking beans and failing
> rollback would imply no transactional semantics have actually changed.  Is
> it possible you can paste that bean?

Re: openejb.xml

[Neale]

Hi Trevor,

Can you tell us your changes/findings so we can adjust the docs to make it 
easier for everyone else?


Best Regards,
Neale



- Original Message - 
From: "Baker, Trevor" 

To: 
Sent: Friday, December 14, 2012 7:10 AM
Subject: RE: openejb.xml


Fixed some line-ending weirdness.

-Original Message-
From: Baker, Trevor [mailto:crba...@mail.ubc.ca]
Sent: Thursday, December 13, 2012 12:07 PM
To: users@openejb.apache.org
Subject: openejb.xml

Hi,

I have the following jndi.properties:


java.naming.factory.initial=org.apache.openejb.client.LocalInitialContextFactory

# create a new data source at: java:/openejb/Resource/dbUnitDS
dbUnitDS=new://Resource?type=DataSource
dbUnitDS.JdbcUrl=jdbc:h2:mem:arquillian;DB_CLOSE_DELAY=-1
dbUnitDS.JdbcDriver=org.h2.Driver
dbUnitDS.JtaManaged=true

# add properties for the persistence unit
test.hibernate.dialect=org.hibernate.dialect.H2Dialect
test.hibernate.hbm2ddl.auto=create-drop
test.hibernate.id.new_generator_mappings=true
---

Unfortunately, jndi.properties is interfering with non-openejb unit tests in 
the project. Would like to convert to openejb.xml but need some help. Can 
someone send back the openejb.xml equivalent. I'm assuming I can place in 
src/test/resources/openejb.xml.


Not being lazy. Just can't find any good resources. Would be nice if this 
page could have a sample openejb.xml: 
http://tomee.apache.org/embedded-configuration.html


Thanks,
Trev 

Simple Netbeans CDI Web Application Not Working

[Kay Wrobel]

Hi everybody.

I am new to TomEE and am having problems with the very basics of getting 
a simple CDI Application to work from Netbeans 7.2. I have added TomEE 
Plus 1.5.0 as a server via the Tools->Servers->Add Server... steps. The 
problem I have is as follows:


I create a simple Web Application with Context and Dependency Injection 
enabled and server-supplied JSF 2.1 implementation activated. I proceed 
to adding a very simple WelcomeBean.java file that looks like this:

package beans;

import java.io.Serializable;
import javax.enterprise.context.SessionScoped;
import javax.inject.Named;

/**
 *
 * @author kuw
 */
@Named(value = "welcomeBean")
@SessionScoped
public class WelcomeBean implements Serializable {

private int counter;

/**
 * Creates a new instance of WelcomeBean
 */
public WelcomeBean() {
}

public String getMessage() {
return super.toString() + String.format(" You called me %d 
times", ++counter);

}
}

and then access that bean from the index.xhtml page like this:



Message is: 


When I run the project, the page simply shows this: "Message is:" and 
the nothing. I can't see anything in the project files that is missing. 
I have the empty shell of beans.xml file to enable CDI, web.xml is 
fairly standard only that I changed the url-pattern for the Faces 
Servlet. Here's the complete web.xml:


http://java.sun.com/xml/ns/javaee"; 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; 
xsi:schemaLocation="http://java.sun.com/xml/ns/javaee 
http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd";>


javax.faces.PROJECT_STAGE
Development


org.apache.myfaces.webapp.StartupServletContextListener


Faces Servlet
javax.faces.webapp.FacesServlet
1


Faces Servlet
*.xhtml



30



index.xhtml




So my question now is: what is going on? I don't see any obvious error 
messages in the different Output tabs in Netbeans.


Btw. If I target the project to the Glassfish server, it works as expected:

Message is: beans.WelcomeBean@77431c1f You called me 3 times

(after reloading page two times).

Anyone here have any idea what I am missing? It has to be something 
essential.


Thanks,

Kay


--

--
The information in this e-mail is confidential and is intended solely for 
the addressee(s). Access to this email by anyone else is unauthorized. If 
you are not an intended recipient, you may not print, save or otherwise 
store the e-mail or any of the contents thereof in electronic or physical 
form, nor copy, use or disseminate the information contained in the email. 
If you are not an intended recipient,  please notify the sender of this 
email immediately.

Re: Why are Tomcat's threads more costly than background threads?

[David Blevins]

On Dec 11, 2012, at 7:10 PM, "Howard W. Smith, Jr."  
wrote:

> Shaking my head... test results were not good at all.
> 
> 1. @StatelessEJB EmailStatelessBean has @Schedule getEmails()
> 2. @EmailStatelessBean has multiple @EJB references to @Stateless
> (sessionfacade) classes that are the DAO classes
> 3. EmailStatelessBean gets invoked when triggered by @Schedule
> 4. EmailStatelessBean execution locks the tables, still, and locks up the
> entire app, and seems to take longer...since endusers (myself) are making
> requests against database (and web app).
> 5. Last but not least, EmailStatelessBean failed to commit the changes;
> transaction rolled back for EmailStatelessBean as well as enduser requests.

The description of EmailStatelessBean still looking beans and failing rollback 
would imply no transactional semantics have actually changed.  Is it possible 
you can paste that bean?


-David

RE: openejb.xml

[Baker, Trevor]

Fixed some line-ending weirdness.

-Original Message-
From: Baker, Trevor [mailto:crba...@mail.ubc.ca] 
Sent: Thursday, December 13, 2012 12:07 PM
To: users@openejb.apache.org
Subject: openejb.xml

Hi,

I have the following jndi.properties:


java.naming.factory.initial=org.apache.openejb.client.LocalInitialContextFactory

# create a new data source at: java:/openejb/Resource/dbUnitDS
dbUnitDS=new://Resource?type=DataSource
dbUnitDS.JdbcUrl=jdbc:h2:mem:arquillian;DB_CLOSE_DELAY=-1
dbUnitDS.JdbcDriver=org.h2.Driver
dbUnitDS.JtaManaged=true

# add properties for the persistence unit
test.hibernate.dialect=org.hibernate.dialect.H2Dialect
test.hibernate.hbm2ddl.auto=create-drop
test.hibernate.id.new_generator_mappings=true
---

Unfortunately, jndi.properties is interfering with non-openejb unit tests in 
the project. Would like to convert to openejb.xml but need some help. Can 
someone send back the openejb.xml equivalent. I'm assuming I can place in 
src/test/resources/openejb.xml.

Not being lazy. Just can't find any good resources. Would be nice if this page 
could have a sample openejb.xml: 
http://tomee.apache.org/embedded-configuration.html

Thanks,
Trev

openejb.xml

[Baker, Trevor]

Hi,

I have the following jndi.properties:

java.naming.factory.initial=org.apache.openejb.client.LocalInitialContextFactory

# create a new data source at: java:/openejb/Resource/dbUnitDS
dbUnitDS=new://Resource?type=DataSource
dbUnitDS.JdbcUrl=jdbc:h2:mem:arquillian;DB_CLOSE_DELAY=-1
dbUnitDS.JdbcDriver=org.h2.Driver
dbUnitDS.JtaManaged=true

# add properties for the persistence unit
test.hibernate.dialect=org.hibernate.dialect.H2Dialect
test.hibernate.hbm2ddl.auto=create-drop
test.hibernate.id.new_generator_mappings=true

Unfortunately, jndi.properties is interfering with non-openejb unit tests in 
the project. Would like to convert to openejb.xml but need some help. Can 
someone send back the openejb.xml equivalent. I'm assuming I can place in 
src/test/resources/openejb.xml.

Not being lazy. Just can't find any good resources. Would be nice if this page 
could have a sample openejb.xml: 
http://tomee.apache.org/embedded-configuration.html

Thanks,
Trev

Re: DB access is very slow

[Howard W. Smith, Jr.]

Sorry, don't understand what you're trying to say here.

@Schedule is used to poll or check an email server for 'specific' emails,
and the emails of interest has JSON embedded, and that JSON are populated
into POJOs via Gson, and then the fun begins... saving that little bit of
data to multiple tables... so endusers don't have to perform 'data entry'
and enter that data 'manually'.

1. The design and implemenation... works as designed

2. the @Stateless EJB with @Schedule getEmails().. works as designed

3. @Stateless EJB (DAO) updating the database.. works as designed but takes
t long.

You all say it is because of the database, but I actually disagree it is
the database, because user click button, CDI-managed-bean updating database
via @Stateless EJB (DAO) is much much faster than #3 listed above.


On Thu, Dec 13, 2012 at 2:37 PM, Romain Manni-Bucau
wrote:

> well your @Schedule == polling no server, it sounds weird by design

Re: DB access is very slow

[Neale]

Hi Romain,

Ah ok that makes sense.  I'm still fairly new to EE thinking ;-)

So if I deploy a new TomEE app, I should use JTA and modify tomee.xml to use 
my DB descriptor - not the Tomcat method of context.xml?


Is this the best doc page on how to configure it?
http://tomee.apache.org/containers-and-resources.html

Is there another page which just shows how to get a simple database-app 
working with JTA on TomEE?  That would be really helpful I think, as most 
users want to do exactly that.


Or an example simple DB app in the examples section?

Best Regards,
Neale




- Original Message - 
From: "Romain Manni-Bucau" 

To: 
Sent: Friday, December 14, 2012 6:37 AM
Subject: Re: DB access is very slow



well your @Schedule == polling no server, it sounds weird by design

@Neale: the default datasource will be a feature of JavaEE 7.
Context.xml stuff should be better on 1.5.1 but we clearly use
tomee.xml by default (and not context.xml) because of jta management
at least

that's said the issues are often easier, often the non jt datasource
is not defined or something like that

Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
LinkedIn: http://fr.linkedin.com/in/rmannibucau
Github: https://github.com/rmannibucau



2012/12/13 Howard W. Smith, Jr. :
Honestly, my preference would be to use @Schedule; I don't want to bug 
the

users and ask/make/require them to click a button to download this data
from email server. TomEE examples has @Schedule on a Singleton bean (I
think that's what I remember, when I saw it). I saw the same in a 
(BalusC)

stackoverflow answer. To this day, I have never used Singleton bean. I
assumed that since I have a CDI @ApplicationScoped bean, then there 
should

be no 'need' to use Singleton bean. Singleton and ApplicationScoped are
both application wide, but now via CDI, it seems as though any/everything
is application-wide, available within any 'context'.

I can accept the notion that my design/implementation is wrong. I've
already learned how to 'improve' my app, specifically for TomEE as the
container, where the app ran perfectly/flawlessly/reliably in Glassfish
(and I'm not alone for saying that).

I'm rewriting code right now, trying to make sure the transaction(s) are 
as

short as possible. Originally, the code was written similar to a batch
process (kinda like the java application I wrote... to migrate data from
dBase IV to the newer/bigger JavaDB... I went from 6-table dbase IV
database to 88+ table JavaDB).

As far as the code sample... David Blevins shared that in another thread. 
I

may have to dig that up.


On Thu, Dec 13, 2012 at 2:16 PM, Romain Manni-Bucau
wrote:


Well Howard think you should try to share with us some sample (not the
full app please)

i used a lot Geronimo transaction manager and i used ( a bit less)
@Schedule and it worked fine

i could understand OpenJPA begin slower on derby but geronimo not
working is a different topic

Side note: maybe your design is wrong, you manage a history in a
@Schedule? not sure that's the best you can do

Re: DB access is very slow

[Howard W. Smith, Jr.]

Interesting what you mentioned about JavaEE7, I remember you advising me to
use tomee.xml and even 'questioned' me... why are you not using tomee.xml
instead of context.xml... remember that?  :)

Well, I'm definitely using JTA, and if I understand you correctly, I think
you are recommending to remove non-jta from my persistence.xml as well as
tomee.xml. Right?



On Thu, Dec 13, 2012 at 2:37 PM, Romain Manni-Bucau
wrote:

> well your @Schedule == polling no server, it sounds weird by design
>
> @Neale: the default datasource will be a feature of JavaEE 7.
> Context.xml stuff should be better on 1.5.1 but we clearly use
> tomee.xml by default (and not context.xml) because of jta management
> at least
>
> that's said the issues are often easier, often the non jt datasource
> is not defined or something like that
>

Re: DB access is very slow

[Romain Manni-Bucau]

well your @Schedule == polling no server, it sounds weird by design

@Neale: the default datasource will be a feature of JavaEE 7.
Context.xml stuff should be better on 1.5.1 but we clearly use
tomee.xml by default (and not context.xml) because of jta management
at least

that's said the issues are often easier, often the non jt datasource
is not defined or something like that

Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
LinkedIn: http://fr.linkedin.com/in/rmannibucau
Github: https://github.com/rmannibucau



2012/12/13 Howard W. Smith, Jr. :
> Honestly, my preference would be to use @Schedule; I don't want to bug the
> users and ask/make/require them to click a button to download this data
> from email server. TomEE examples has @Schedule on a Singleton bean (I
> think that's what I remember, when I saw it). I saw the same in a (BalusC)
> stackoverflow answer. To this day, I have never used Singleton bean. I
> assumed that since I have a CDI @ApplicationScoped bean, then there should
> be no 'need' to use Singleton bean. Singleton and ApplicationScoped are
> both application wide, but now via CDI, it seems as though any/everything
> is application-wide, available within any 'context'.
>
> I can accept the notion that my design/implementation is wrong. I've
> already learned how to 'improve' my app, specifically for TomEE as the
> container, where the app ran perfectly/flawlessly/reliably in Glassfish
> (and I'm not alone for saying that).
>
> I'm rewriting code right now, trying to make sure the transaction(s) are as
> short as possible. Originally, the code was written similar to a batch
> process (kinda like the java application I wrote... to migrate data from
> dBase IV to the newer/bigger JavaDB... I went from 6-table dbase IV
> database to 88+ table JavaDB).
>
> As far as the code sample... David Blevins shared that in another thread. I
> may have to dig that up.
>
>
> On Thu, Dec 13, 2012 at 2:16 PM, Romain Manni-Bucau
> wrote:
>
>> Well Howard think you should try to share with us some sample (not the
>> full app please)
>>
>> i used a lot Geronimo transaction manager and i used ( a bit less)
>> @Schedule and it worked fine
>>
>> i could understand OpenJPA begin slower on derby but geronimo not
>> working is a different topic
>>
>> Side note: maybe your design is wrong, you manage a history in a
>> @Schedule? not sure that's the best you can do
>>

Re: Unable to configure MYSQL resource in tomee.xml

[Romain Manni-Bucau]

did you put mysql driver in tomee/lib?

Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
LinkedIn: http://fr.linkedin.com/in/rmannibucau
Github: https://github.com/rmannibucau



2012/12/13 avrono :
> Hi Neale,
>
>
> Had a similar thought. Will try another Grep ... Not found anything thus
> far.
>
>
>
> --
> View this message in context: 
> http://openejb.979440.n4.nabble.com/Unable-to-configure-MYSQL-resource-in-tomee-xml-tp4659538p4659560.html
> Sent from the OpenEJB User mailing list archive at Nabble.com.

Re: DB access is very slow

[Howard W. Smith, Jr.]

Honestly, my preference would be to use @Schedule; I don't want to bug the
users and ask/make/require them to click a button to download this data
from email server. TomEE examples has @Schedule on a Singleton bean (I
think that's what I remember, when I saw it). I saw the same in a (BalusC)
stackoverflow answer. To this day, I have never used Singleton bean. I
assumed that since I have a CDI @ApplicationScoped bean, then there should
be no 'need' to use Singleton bean. Singleton and ApplicationScoped are
both application wide, but now via CDI, it seems as though any/everything
is application-wide, available within any 'context'.

I can accept the notion that my design/implementation is wrong. I've
already learned how to 'improve' my app, specifically for TomEE as the
container, where the app ran perfectly/flawlessly/reliably in Glassfish
(and I'm not alone for saying that).

I'm rewriting code right now, trying to make sure the transaction(s) are as
short as possible. Originally, the code was written similar to a batch
process (kinda like the java application I wrote... to migrate data from
dBase IV to the newer/bigger JavaDB... I went from 6-table dbase IV
database to 88+ table JavaDB).

As far as the code sample... David Blevins shared that in another thread. I
may have to dig that up.


On Thu, Dec 13, 2012 at 2:16 PM, Romain Manni-Bucau
wrote:

> Well Howard think you should try to share with us some sample (not the
> full app please)
>
> i used a lot Geronimo transaction manager and i used ( a bit less)
> @Schedule and it worked fine
>
> i could understand OpenJPA begin slower on derby but geronimo not
> working is a different topic
>
> Side note: maybe your design is wrong, you manage a history in a
> @Schedule? not sure that's the best you can do
>

Re: Unable to configure MYSQL resource in tomee.xml

[avrono]

Hi Neale,


Had a similar thought. Will try another Grep ... Not found anything thus
far.



--
View this message in context: 
http://openejb.979440.n4.nabble.com/Unable-to-configure-MYSQL-resource-in-tomee-xml-tp4659538p4659560.html
Sent from the OpenEJB User mailing list archive at Nabble.com.

Re: DB access is very slow

[Neale]

Actually I'd recommend removing the default HSQLDB reference in tomee.xml

I'm not sure if it's used for one of the examples or what it's used for, but 
every time I"ve deployed a TomEE instance I've had to remove/disable it 
manually because it overrides my real database definition 
(META-INF/context.xml)


If it's used for something, maybe that should be documented somewhere?  Or 
otherwise maybe the release versions of TomEE can include it, but maybe have 
it commented out?


Best Regards,
Neale


- Original Message - 
From: "Romain Manni-Bucau" 

To: 
Sent: Friday, December 14, 2012 6:16 AM
Subject: Re: DB access is very slow



hard to come back now ;)

back  on the topic,

Well Howard think you should try to share with us some sample (not the
full app please)

i used a lot Geronimo transaction manager and i used ( a bit less)
@Schedule and it worked fine

i could understand OpenJPA begin slower on derby but geronimo not
working is a different topic

Side note: maybe your design is wrong, you manage a history in a
@Schedule? not sure that's the best you can do

Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
LinkedIn: http://fr.linkedin.com/in/rmannibucau
Github: https://github.com/rmannibucau



2012/12/13 Neale :

Romain is great :-)


- Original Message - From: "Howard W. Smith, Jr."

To: 
Sent: Friday, December 14, 2012 6:09 AM

Subject: Re: DB access is very slow



Thank you very much Neale for all your responses. I have been open to
searching around for a good java web host, but just didn't find it
necessary...yet. At some point, I may be interested in your TomEE 
hosting
service; when the project reaches a larger scope of endusers. Right now, 
I

think we are doing okay with the hardware in place (and planning to have
in
place).

I'll do my best to take any/all of your suggestions...especially about
high
volume. Romain is funny...he seems to welcome any/all discussion related
to
'using TomEE'. :)


On Thu, Dec 13, 2012 at 2:04 PM, Neale  wrote:


Hi Howard,

Your discussions are very interesting - I haven't unsubscribed from the
TomEE list yet even though there is such high volume.  Lately I 
actually

quite enjoy following your progress.  There are a lot of emails - but
just
don't get too off-topic ;-)  Try a few things on your own, then bring
your
findings to the list.  Some questions are a bit off-topic so they're
better
being discussed on other lists.

It's really exciting seeing you using TomEE for the first time and
running
into the initial problems.  Those problems are very interesting.  When 
we
get to discussing Derby vs Hyper vs MySQL however, it's better to do 
some

independant research and come back to the list afterwards.  (IMHO)

Anyway - I'd love to hear more about how your project turns out, and if
you want some free hosting on our new TomEE cluster, drop me a private
email and I'd be happy to give you some free space.  Any experience we
have
with commerical TomEE customers is a great experience for us that we 
can

blog about or share with the TomEE devs.

Best Regards,
Neale



- Original Message - From: "Howard W. Smith, Jr." <
smithh032...@gmail.com>
To: 
Sent: Friday, December 14, 2012 5:50 AM

Subject: Re: DB access is very slow


 Agreed about Romain, he is very amazing. Noted about HyperSQL, will
avoid


that, and understood about 17mb = "playing". This is a new app that 
I've

developed and it's being used every day for 'business', so definitely
not
playing, but I do want to move to prime-time and a faster database, so 
I

will do that, ASAP. Thanks Neale.

TomEE committers already admit that TomEE is not 'perfect'...yet, so I
would assume these discussions are welcome. Honestly, I do my best to
make
sure I am on topic. I'm sure TomEE and OpenEJB is responsible for the
@Stateless EJB transaction, triggered by @Schedule, and why is TomEE
performing well with Derby when user click button, and managed beans
call
@Stateless EJB (DAO) to perform database operations... but why is 
TomEE

not
allowing my @Stateless EJB with @Schedule method() to perform
well...with
a
large transaction.

I have heard that geronimo has many many issues and does not have a 
good

name/reputation, but regardless of the negative chatter I've seen on
stackoverflow about geronimo, I still continue to use TomEE and I
communicate my issues here on the list.



On Thu, Dec 13, 2012 at 1:39 PM, Neale  wrote:

 HyperSQL is another toy.



The specs below are great, Derby looks good in some cases, bad in
others.
But once again this is a very small test database.

You might get 10% performance increase moving your database from 
derby

to
mysql, or you might get a 10% performance loss.  If you plan to use 
it
commercially, use a real database because you will avoid all the 
issues

when the database grows.  All our (non-student) databases here are
300mb-12gb. That is a very big difference to 17mb, but it depends on
what
data they store and how long

Re: Unable to configure MYSQL resource in tomee.xml

[Neale]

Hi Avrono,

The hint for me was that I was using MySQL only, and wasn't using hsqldb - 
but the error was hsqldb.


I removed all the hsqldb references and got it working.

It looks like you already removed all the hsqldb refs from tomee.xml though, 
so that's confusing.  Maybe someone else knows where hsqldb is being 
referenced?


As far as I know:
tomee.xml
 elements
META-INF/context.xml (my preference - and I had to remove the others to get 
this to be recognised)


Romain?  Jean-Louis?

Best Regards,
Neale



- Original Message - 
From: "avrono" 

To: 
Sent: Friday, December 14, 2012 6:18 AM
Subject: Re: Unable to configure MYSQL resource in tomee.xml



Hi Neale,

I had the same thought and tried to grep for any other DB references. I
guess configuration is becomming a minefield. Here is the tomee.xml








 # Specifies the maximum time an invocation could wait for the
 # singleton bean instance to become available before giving up.
 #
 # After the timeout is reached a
javax.ejb.ConcurrentAccessTimeoutException
 # will be thrown.
 #
 # Usable time units: nanoseconds, microsecons, milliseconds,
 # seconds, minutes, hours, days.  Or any combination such as
 # "1 hour and 27 minutes and 10 seconds"

 AccessTimeout = 30 seconds





 # Specifies the maximum time an invocation could wait for the
 # stateful bean instance to become available before giving up.
 #
 # After the timeout is reached a
javax.ejb.ConcurrentAccessTimeoutException
 # will be thrown.
 #
 # Usable time units: nanoseconds, microsecons, milliseconds,
 # seconds, minutes, hours, days.  Or any combination such as
 # "1 hour and 27 minutes and 10 seconds"

 AccessTimeout = 30 seconds

 #  The passivator is responsible for writing beans to disk
 #  at passivation time. Different passivators can be used
 #  by setting this property to the fully qualified class name
 #  of the PassivationStrategy implementation. The passivator
 #  is not responsible for invoking any callbacks or other
 #  processing, its only responsibly is to write the bean state
 #  to disk.
 #
 #  Known implementations:
 # org.apache.openejb.core.stateful.RAFPassivater
 # org.apache.openejb.core.stateful.SimplePassivater

 Passivator   org.apache.openejb.core.stateful.SimplePassivater

 #  Specifies the time to wait between invocations. This
 #  value is measured in minutes. A value of 5 would
 #  result in a time-out of 5 minutes between invocations.
 #  A value of zero would mean no timeout.

 TimeOut  20

 # Specifies the frequency (in seconds) at which the bean cache is checked
for
 # idle beans.

 Frequency 60

 #  Specifies the size of the bean pools for this
 #  stateful SessionBean container.

 Capacity  1000

 #  Property name that specifies the number of instances
 #  to passivate at one time when doing bulk passivation.
 #  Must be less than the PoolSize.

 BulkPassivate  100






 # Specifies the time an invokation should wait for an instance
 # of the pool to become available.
 #
 # After the timeout is reached, if an instance in the pool cannot
 # be obtained, the method invocation will fail.
 #
 # Usable time units: nanoseconds, microsecons, milliseconds,
 # seconds, minutes, hours, days.  Or any combination such as
 # "1 hour and 27 minutes and 10 seconds"

 AccessTimeout = 30 seconds

 # Specifies the size of the bean pools for this stateless
 # SessionBean container.  If StrictPooling is not used, instances
 # will still be created beyond this number if there is demand, but
 # they will not be returned to the pool and instead will be
 # immediately destroyed.

 MaxSize = 10

 # Specifies the minimum number of bean instances that should be in
 # the pool for each bean.  Pools are prefilled to the minimum on
 # startup.  Note this will create start order dependencies between
 # other beans that also eagerly start, such as other @Stateless
 # beans with a minimum or @Singleton beans using @Startup.  The
 # @DependsOn annotation can be used to appropriately influence
 # start order.
 #
 # The minimum pool size is rigidly maintained.  Instances in the
 # minimum side of the pool are not eligible for IdleTimeout or
 # GarbageCollection, but are subject to MaxAge and flushing.
 #
 # If the pool is flushed it is immediately refilled to the minimum
 # size with MaxAgeOffset applied.  If an instance from the minimum
 # side of the pool reaches its MaxAge, it is also immediately
 # replaced.  Replacement is done in a background queue using the
 # number of threads specified by CallbackThreads.

 MinSize = 0

 # StrictPooling tells the container what to do when the pool
 # reaches it's maximum size and there are incoming requests that
 # need instances.
 #
 # With strict pooling, requests will have to wait for instances to
 # become available. The pool size will never grow beyond the the
 # set MaxSize value.  The maximum amount of time a request should
 # wait is specified via the AccessTimeout setting.
 #
 # Without strict pooling, the container

Re: DB access is very slow

[Neale]

Definitely ask him about all the @stuff.

That's his area!


- Original Message - 
From: "Howard W. Smith, Jr." 

To: 
Sent: Friday, December 14, 2012 6:09 AM
Subject: Re: DB access is very slow



Thank you very much Neale for all your responses. I have been open to
searching around for a good java web host, but just didn't find it
necessary...yet. At some point, I may be interested in your TomEE hosting
service; when the project reaches a larger scope of endusers. Right now, I
think we are doing okay with the hardware in place (and planning to have 
in

place).

I'll do my best to take any/all of your suggestions...especially about 
high
volume. Romain is funny...he seems to welcome any/all discussion related 
to

'using TomEE'. :)


On Thu, Dec 13, 2012 at 2:04 PM, Neale  wrote:


Hi Howard,

Your discussions are very interesting - I haven't unsubscribed from the
TomEE list yet even though there is such high volume.  Lately I actually
quite enjoy following your progress.  There are a lot of emails - but 
just
don't get too off-topic ;-)  Try a few things on your own, then bring 
your
findings to the list.  Some questions are a bit off-topic so they're 
better

being discussed on other lists.

It's really exciting seeing you using TomEE for the first time and 
running

into the initial problems.  Those problems are very interesting.  When we
get to discussing Derby vs Hyper vs MySQL however, it's better to do some
independant research and come back to the list afterwards.  (IMHO)

Anyway - I'd love to hear more about how your project turns out, and if
you want some free hosting on our new TomEE cluster, drop me a private
email and I'd be happy to give you some free space.  Any experience we 
have

with commerical TomEE customers is a great experience for us that we can
blog about or share with the TomEE devs.

Best Regards,
Neale



- Original Message - From: "Howard W. Smith, Jr." <
smithh032...@gmail.com>
To: 
Sent: Friday, December 14, 2012 5:50 AM

Subject: Re: DB access is very slow


 Agreed about Romain, he is very amazing. Noted about HyperSQL, will 
avoid

that, and understood about 17mb = "playing". This is a new app that I've
developed and it's being used every day for 'business', so definitely 
not

playing, but I do want to move to prime-time and a faster database, so I
will do that, ASAP. Thanks Neale.

TomEE committers already admit that TomEE is not 'perfect'...yet, so I
would assume these discussions are welcome. Honestly, I do my best to 
make

sure I am on topic. I'm sure TomEE and OpenEJB is responsible for the
@Stateless EJB transaction, triggered by @Schedule, and why is TomEE
performing well with Derby when user click button, and managed beans 
call

@Stateless EJB (DAO) to perform database operations... but why is TomEE
not
allowing my @Stateless EJB with @Schedule method() to perform 
well...with

a
large transaction.

I have heard that geronimo has many many issues and does not have a good
name/reputation, but regardless of the negative chatter I've seen on
stackoverflow about geronimo, I still continue to use TomEE and I
communicate my issues here on the list.



On Thu, Dec 13, 2012 at 1:39 PM, Neale  wrote:

 HyperSQL is another toy.


The specs below are great, Derby looks good in some cases, bad in 
others.

But once again this is a very small test database.

You might get 10% performance increase moving your database from derby 
to

mysql, or you might get a 10% performance loss.  If you plan to use it
commercially, use a real database because you will avoid all the issues
when the database grows.  All our (non-student) databases here are
300mb-12gb. That is a very big difference to 17mb, but it depends on 
what

data they store and how long they keep it.  17mb is just "playing".  So
10%
performance difference up or down is not much fun to look at.

Anyway - I don't think this is relevant to the TomEE list, and all the
users/developers receiving these emails 10-20 times per day are 
probably

not interested at all.  It's very important to keep the discussion
relevant
so that people don't leave the TomEE list.   The list gains more 
members

from people seeing relevant information and staying subscribed, so we
shouldn't really discuss this here as it's off-topic.

You are saying your real problem is JPA, so please try on another
database, and cut the problem into smaller pieces.  Then you will 
quickly

find out if it's a Derby issue, a JPA issue, or a TomEE issue.

If TomEE is performing badly compared to Tomcat or JPA on a 
command-line

JVM, then I'm sure the TomEE devs will jump on the issue and fix it as
soon
as possible.  Romain is quite amazing, if he sees a problem with TomEE,
he
leaps on it!   So let's try to limit the number of emails to be real
TomEE
issues so we don't waste his time ;-)

Best Regards,
Neale

Re: Unable to configure MYSQL resource in tomee.xml

[avrono]

Hi Neale, 

I had the same thought and tried to grep for any other DB references. I
guess configuration is becomming a minefield. Here is the tomee.xml








  # Specifies the maximum time an invocation could wait for the
  # singleton bean instance to become available before giving up.
  #
  # After the timeout is reached a
javax.ejb.ConcurrentAccessTimeoutException
  # will be thrown.
  #
  # Usable time units: nanoseconds, microsecons, milliseconds,
  # seconds, minutes, hours, days.  Or any combination such as
  # "1 hour and 27 minutes and 10 seconds"

  AccessTimeout = 30 seconds





  # Specifies the maximum time an invocation could wait for the
  # stateful bean instance to become available before giving up.
  #
  # After the timeout is reached a
javax.ejb.ConcurrentAccessTimeoutException
  # will be thrown.
  #
  # Usable time units: nanoseconds, microsecons, milliseconds,
  # seconds, minutes, hours, days.  Or any combination such as
  # "1 hour and 27 minutes and 10 seconds"

  AccessTimeout = 30 seconds

  #  The passivator is responsible for writing beans to disk
  #  at passivation time. Different passivators can be used
  #  by setting this property to the fully qualified class name
  #  of the PassivationStrategy implementation. The passivator
  #  is not responsible for invoking any callbacks or other
  #  processing, its only responsibly is to write the bean state
  #  to disk.
  #
  #  Known implementations:
  # org.apache.openejb.core.stateful.RAFPassivater
  # org.apache.openejb.core.stateful.SimplePassivater

  Passivator   org.apache.openejb.core.stateful.SimplePassivater

  #  Specifies the time to wait between invocations. This
  #  value is measured in minutes. A value of 5 would
  #  result in a time-out of 5 minutes between invocations.
  #  A value of zero would mean no timeout.

  TimeOut  20

  # Specifies the frequency (in seconds) at which the bean cache is checked
for
  # idle beans.

  Frequency 60

  #  Specifies the size of the bean pools for this
  #  stateful SessionBean container.

  Capacity  1000

  #  Property name that specifies the number of instances
  #  to passivate at one time when doing bulk passivation.
  #  Must be less than the PoolSize.

  BulkPassivate  100






  # Specifies the time an invokation should wait for an instance
  # of the pool to become available.
  #
  # After the timeout is reached, if an instance in the pool cannot
  # be obtained, the method invocation will fail.
  #
  # Usable time units: nanoseconds, microsecons, milliseconds,
  # seconds, minutes, hours, days.  Or any combination such as
  # "1 hour and 27 minutes and 10 seconds"

  AccessTimeout = 30 seconds

  # Specifies the size of the bean pools for this stateless
  # SessionBean container.  If StrictPooling is not used, instances
  # will still be created beyond this number if there is demand, but
  # they will not be returned to the pool and instead will be
  # immediately destroyed.

  MaxSize = 10

  # Specifies the minimum number of bean instances that should be in
  # the pool for each bean.  Pools are prefilled to the minimum on
  # startup.  Note this will create start order dependencies between
  # other beans that also eagerly start, such as other @Stateless
  # beans with a minimum or @Singleton beans using @Startup.  The
  # @DependsOn annotation can be used to appropriately influence
  # start order.
  #
  # The minimum pool size is rigidly maintained.  Instances in the
  # minimum side of the pool are not eligible for IdleTimeout or
  # GarbageCollection, but are subject to MaxAge and flushing.
  #
  # If the pool is flushed it is immediately refilled to the minimum
  # size with MaxAgeOffset applied.  If an instance from the minimum
  # side of the pool reaches its MaxAge, it is also immediately
  # replaced.  Replacement is done in a background queue using the
  # number of threads specified by CallbackThreads.

  MinSize = 0

  # StrictPooling tells the container what to do when the pool
  # reaches it's maximum size and there are incoming requests that
  # need instances.
  #
  # With strict pooling, requests will have to wait for instances to
  # become available. The pool size will never grow beyond the the
  # set MaxSize value.  The maximum amount of time a request should
  # wait is specified via the AccessTimeout setting.
  #
  # Without strict pooling, the container will create temporary
  # instances to meet demand. The instances will last for just one
  # method invocation and then are removed.
  #
  # Setting StrictPooling to false and MaxSize to 0 will result in
  # no pooling. Instead instances will be created on demand and live
  # for exactly one method call before being removed.

  StrictPooling = true

  # Specifies the maximum time that an instance should live before
  # it should be retired and removed from use.  This will happen
  # gracefully.  Useful for situations where bean instances are
  # designed to hold potentially exp

Re: DB access is very slow

[Romain Manni-Bucau]

hard to come back now ;)

back  on the topic,

Well Howard think you should try to share with us some sample (not the
full app please)

i used a lot Geronimo transaction manager and i used ( a bit less)
@Schedule and it worked fine

i could understand OpenJPA begin slower on derby but geronimo not
working is a different topic

Side note: maybe your design is wrong, you manage a history in a
@Schedule? not sure that's the best you can do

Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
LinkedIn: http://fr.linkedin.com/in/rmannibucau
Github: https://github.com/rmannibucau



2012/12/13 Neale :
> Romain is great :-)
>
>
> - Original Message - From: "Howard W. Smith, Jr."
> 
> To: 
> Sent: Friday, December 14, 2012 6:09 AM
>
> Subject: Re: DB access is very slow
>
>
>> Thank you very much Neale for all your responses. I have been open to
>> searching around for a good java web host, but just didn't find it
>> necessary...yet. At some point, I may be interested in your TomEE hosting
>> service; when the project reaches a larger scope of endusers. Right now, I
>> think we are doing okay with the hardware in place (and planning to have
>> in
>> place).
>>
>> I'll do my best to take any/all of your suggestions...especially about
>> high
>> volume. Romain is funny...he seems to welcome any/all discussion related
>> to
>> 'using TomEE'. :)
>>
>>
>> On Thu, Dec 13, 2012 at 2:04 PM, Neale  wrote:
>>
>>> Hi Howard,
>>>
>>> Your discussions are very interesting - I haven't unsubscribed from the
>>> TomEE list yet even though there is such high volume.  Lately I actually
>>> quite enjoy following your progress.  There are a lot of emails - but
>>> just
>>> don't get too off-topic ;-)  Try a few things on your own, then bring
>>> your
>>> findings to the list.  Some questions are a bit off-topic so they're
>>> better
>>> being discussed on other lists.
>>>
>>> It's really exciting seeing you using TomEE for the first time and
>>> running
>>> into the initial problems.  Those problems are very interesting.  When we
>>> get to discussing Derby vs Hyper vs MySQL however, it's better to do some
>>> independant research and come back to the list afterwards.  (IMHO)
>>>
>>> Anyway - I'd love to hear more about how your project turns out, and if
>>> you want some free hosting on our new TomEE cluster, drop me a private
>>> email and I'd be happy to give you some free space.  Any experience we
>>> have
>>> with commerical TomEE customers is a great experience for us that we can
>>> blog about or share with the TomEE devs.
>>>
>>> Best Regards,
>>> Neale
>>>
>>>
>>>
>>> - Original Message - From: "Howard W. Smith, Jr." <
>>> smithh032...@gmail.com>
>>> To: 
>>> Sent: Friday, December 14, 2012 5:50 AM
>>>
>>> Subject: Re: DB access is very slow
>>>
>>>
>>>  Agreed about Romain, he is very amazing. Noted about HyperSQL, will
>>> avoid

 that, and understood about 17mb = "playing". This is a new app that I've
 developed and it's being used every day for 'business', so definitely
 not
 playing, but I do want to move to prime-time and a faster database, so I
 will do that, ASAP. Thanks Neale.

 TomEE committers already admit that TomEE is not 'perfect'...yet, so I
 would assume these discussions are welcome. Honestly, I do my best to
 make
 sure I am on topic. I'm sure TomEE and OpenEJB is responsible for the
 @Stateless EJB transaction, triggered by @Schedule, and why is TomEE
 performing well with Derby when user click button, and managed beans
 call
 @Stateless EJB (DAO) to perform database operations... but why is TomEE
 not
 allowing my @Stateless EJB with @Schedule method() to perform
 well...with
 a
 large transaction.

 I have heard that geronimo has many many issues and does not have a good
 name/reputation, but regardless of the negative chatter I've seen on
 stackoverflow about geronimo, I still continue to use TomEE and I
 communicate my issues here on the list.



 On Thu, Dec 13, 2012 at 1:39 PM, Neale  wrote:

  HyperSQL is another toy.
>
>
> The specs below are great, Derby looks good in some cases, bad in
> others.
> But once again this is a very small test database.
>
> You might get 10% performance increase moving your database from derby
> to
> mysql, or you might get a 10% performance loss.  If you plan to use it
> commercially, use a real database because you will avoid all the issues
> when the database grows.  All our (non-student) databases here are
> 300mb-12gb. That is a very big difference to 17mb, but it depends on
> what
> data they store and how long they keep it.  17mb is just "playing".  So
> 10%
> performance difference up or down is not much fun to look at.
>
> Anyway - I don't think this is relevant to the TomEE list, and all the
> users/developers receivi

Re: DB access is very slow

[Neale]

Romain is great :-)

- Original Message - 
From: "Howard W. Smith, Jr." 

To: 
Sent: Friday, December 14, 2012 6:09 AM
Subject: Re: DB access is very slow



Thank you very much Neale for all your responses. I have been open to
searching around for a good java web host, but just didn't find it
necessary...yet. At some point, I may be interested in your TomEE hosting
service; when the project reaches a larger scope of endusers. Right now, I
think we are doing okay with the hardware in place (and planning to have 
in

place).

I'll do my best to take any/all of your suggestions...especially about 
high
volume. Romain is funny...he seems to welcome any/all discussion related 
to

'using TomEE'. :)


On Thu, Dec 13, 2012 at 2:04 PM, Neale  wrote:


Hi Howard,

Your discussions are very interesting - I haven't unsubscribed from the
TomEE list yet even though there is such high volume.  Lately I actually
quite enjoy following your progress.  There are a lot of emails - but 
just
don't get too off-topic ;-)  Try a few things on your own, then bring 
your
findings to the list.  Some questions are a bit off-topic so they're 
better

being discussed on other lists.

It's really exciting seeing you using TomEE for the first time and 
running

into the initial problems.  Those problems are very interesting.  When we
get to discussing Derby vs Hyper vs MySQL however, it's better to do some
independant research and come back to the list afterwards.  (IMHO)

Anyway - I'd love to hear more about how your project turns out, and if
you want some free hosting on our new TomEE cluster, drop me a private
email and I'd be happy to give you some free space.  Any experience we 
have

with commerical TomEE customers is a great experience for us that we can
blog about or share with the TomEE devs.

Best Regards,
Neale



- Original Message - From: "Howard W. Smith, Jr." <
smithh032...@gmail.com>
To: 
Sent: Friday, December 14, 2012 5:50 AM

Subject: Re: DB access is very slow


 Agreed about Romain, he is very amazing. Noted about HyperSQL, will 
avoid

that, and understood about 17mb = "playing". This is a new app that I've
developed and it's being used every day for 'business', so definitely 
not

playing, but I do want to move to prime-time and a faster database, so I
will do that, ASAP. Thanks Neale.

TomEE committers already admit that TomEE is not 'perfect'...yet, so I
would assume these discussions are welcome. Honestly, I do my best to 
make

sure I am on topic. I'm sure TomEE and OpenEJB is responsible for the
@Stateless EJB transaction, triggered by @Schedule, and why is TomEE
performing well with Derby when user click button, and managed beans 
call

@Stateless EJB (DAO) to perform database operations... but why is TomEE
not
allowing my @Stateless EJB with @Schedule method() to perform 
well...with

a
large transaction.

I have heard that geronimo has many many issues and does not have a good
name/reputation, but regardless of the negative chatter I've seen on
stackoverflow about geronimo, I still continue to use TomEE and I
communicate my issues here on the list.



On Thu, Dec 13, 2012 at 1:39 PM, Neale  wrote:

 HyperSQL is another toy.


The specs below are great, Derby looks good in some cases, bad in 
others.

But once again this is a very small test database.

You might get 10% performance increase moving your database from derby 
to

mysql, or you might get a 10% performance loss.  If you plan to use it
commercially, use a real database because you will avoid all the issues
when the database grows.  All our (non-student) databases here are
300mb-12gb. That is a very big difference to 17mb, but it depends on 
what

data they store and how long they keep it.  17mb is just "playing".  So
10%
performance difference up or down is not much fun to look at.

Anyway - I don't think this is relevant to the TomEE list, and all the
users/developers receiving these emails 10-20 times per day are 
probably

not interested at all.  It's very important to keep the discussion
relevant
so that people don't leave the TomEE list.   The list gains more 
members

from people seeing relevant information and staying subscribed, so we
shouldn't really discuss this here as it's off-topic.

You are saying your real problem is JPA, so please try on another
database, and cut the problem into smaller pieces.  Then you will 
quickly

find out if it's a Derby issue, a JPA issue, or a TomEE issue.

If TomEE is performing badly compared to Tomcat or JPA on a 
command-line

JVM, then I'm sure the TomEE devs will jump on the issue and fix it as
soon
as possible.  Romain is quite amazing, if he sees a problem with TomEE,
he
leaps on it!   So let's try to limit the number of emails to be real
TomEE
issues so we don't waste his time ;-)

Best Regards,
Neale

Re: Unable to configure MYSQL resource in tomee.xml

[Neale]

Hi Avron,

Can you paste your entire tomee.xml?

I had the same problem when I started using TomEE because of the default 
database definitions in there.  If you remove the other definitions, it 
should use the database you defined.


Best Regards,
Neale

- Original Message - 
From: "avrono" 

To: 
Sent: Friday, December 14, 2012 5:43 AM
Subject: Unable to configure MYSQL resource in tomee.xml



Hi,

I am having a problem with configuring a database connection. I Have 
managed

to write to the database using   DriverManager but not with @Resource.

I have the following in my tomee.xml


 JdbcDriver com.mysql.jdbc.Driver
 JdbcUrl jdbc:mysql://localhost:3306/mydb
 UserName myuser
 Password mypass
 JtaManaged true



in my ManagedBean, I have

@Resource(name="MyDataSource", type=javax.sql.DataSource.class)
Private DataSource dataSource;


I have a @PostConstruct

with 

try {
 connection = dataSource.getConnection();
} catch (Exception ex) {
ex.printStackTrace();
}


The Connection does not throw an exception , however when I try write to 
the

connection

try {
  stmt = connection.createStatement();
  stmt.executeUpdate(insert_string)
} catch (Exception ex) {
  ex.printStackTrace()
}


I get

Query is java.sql.SQLSyntaxErrorException: user lacks privilege or object not 
found:

ITEM
at org.hsqldb.jdbc.Util.sqlException(Unknown Source)
at org.hsqldb.jdbc.Util.sqlException(Unknown Source)
at org.hsqldb.jdbc.JDBCStatement.fetchResult(Unknown Source)
at org.hsqldb.jdbc.JDBCStatement.executeUpdate(Unknown Source)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
org.apache.tomcat.jdbc.pool.interceptor.StatementDecoratorInterceptor$StatementProxy.invoke(StatementDecoratorInterceptor.java:238)
at $Proxy83.executeUpdate(Unknown Source)
at com.prsx.ItemAdder.addItem(ItemAdder.java:101)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.apache.el.parser.AstValue.invoke(AstValue.java:278)
at 
org.apache.el.MethodExpressionImpl.invoke(MethodExpressionImpl.java:274)

at
org.apache.jasper.el.JspMethodExpression.invoke(JspMethodExpression.java:70)
at
org.apache.myfaces.application.ActionListenerImpl.processAction(ActionListenerImpl.java:68)
at javax.faces.component.UICommand.broadcast(UICommand.java:120)
at javax.faces.component.UIViewRoot._broadcastAll(UIViewRoot.java:1028)
at javax.faces.component.UIViewRoot.broadcastEvents(UIViewRoot.java:286)
at javax.faces.component.UIViewRoot._process(UIViewRoot.java:1375)
at 
javax.faces.component.UIViewRoot.processApplication(UIViewRoot.java:752)

at
org.apache.myfaces.lifecycle.InvokeApplicationExecutor.execute(InvokeApplicationExecutor.java:38)
at
org.apache.myfaces.lifecycle.LifecycleImpl.executePhase(LifecycleImpl.java:170)
at
org.apache.myfaces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:117)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:197)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:305)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:222)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:123)
at org.apache.tomee.catalina.OpenEJBValve.invoke(OpenEJBValve.java:45)
at
org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:472)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:168)
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:99)
at
org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:929)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118)
at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:407)
at
org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1002)
at
org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:585)
at
org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:310)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)
Caused by: org.hsqldb.HsqlException: user lacks privilege or object not
found: ITEM
at org.hsqldb.error.Error.error(Unknown Source)
at org.hsqldb.error.Error.error(Unknown Source)
at org.hsqldb.SchemaManager.getTable(Unknown Source)
at org.h

Re: DB access is very slow

[Howard W. Smith, Jr.]

Thank you very much Neale for all your responses. I have been open to
searching around for a good java web host, but just didn't find it
necessary...yet. At some point, I may be interested in your TomEE hosting
service; when the project reaches a larger scope of endusers. Right now, I
think we are doing okay with the hardware in place (and planning to have in
place).

I'll do my best to take any/all of your suggestions...especially about high
volume. Romain is funny...he seems to welcome any/all discussion related to
'using TomEE'. :)


On Thu, Dec 13, 2012 at 2:04 PM, Neale  wrote:

> Hi Howard,
>
> Your discussions are very interesting - I haven't unsubscribed from the
> TomEE list yet even though there is such high volume.  Lately I actually
> quite enjoy following your progress.  There are a lot of emails - but just
> don't get too off-topic ;-)  Try a few things on your own, then bring your
> findings to the list.  Some questions are a bit off-topic so they're better
> being discussed on other lists.
>
> It's really exciting seeing you using TomEE for the first time and running
> into the initial problems.  Those problems are very interesting.  When we
> get to discussing Derby vs Hyper vs MySQL however, it's better to do some
> independant research and come back to the list afterwards.  (IMHO)
>
> Anyway - I'd love to hear more about how your project turns out, and if
> you want some free hosting on our new TomEE cluster, drop me a private
> email and I'd be happy to give you some free space.  Any experience we have
> with commerical TomEE customers is a great experience for us that we can
> blog about or share with the TomEE devs.
>
> Best Regards,
> Neale
>
>
>
> - Original Message - From: "Howard W. Smith, Jr." <
> smithh032...@gmail.com>
> To: 
> Sent: Friday, December 14, 2012 5:50 AM
>
> Subject: Re: DB access is very slow
>
>
>  Agreed about Romain, he is very amazing. Noted about HyperSQL, will avoid
>> that, and understood about 17mb = "playing". This is a new app that I've
>> developed and it's being used every day for 'business', so definitely not
>> playing, but I do want to move to prime-time and a faster database, so I
>> will do that, ASAP. Thanks Neale.
>>
>> TomEE committers already admit that TomEE is not 'perfect'...yet, so I
>> would assume these discussions are welcome. Honestly, I do my best to make
>> sure I am on topic. I'm sure TomEE and OpenEJB is responsible for the
>> @Stateless EJB transaction, triggered by @Schedule, and why is TomEE
>> performing well with Derby when user click button, and managed beans call
>> @Stateless EJB (DAO) to perform database operations... but why is TomEE
>> not
>> allowing my @Stateless EJB with @Schedule method() to perform well...with
>> a
>> large transaction.
>>
>> I have heard that geronimo has many many issues and does not have a good
>> name/reputation, but regardless of the negative chatter I've seen on
>> stackoverflow about geronimo, I still continue to use TomEE and I
>> communicate my issues here on the list.
>>
>>
>>
>> On Thu, Dec 13, 2012 at 1:39 PM, Neale  wrote:
>>
>>  HyperSQL is another toy.
>>>
>>> The specs below are great, Derby looks good in some cases, bad in others.
>>> But once again this is a very small test database.
>>>
>>> You might get 10% performance increase moving your database from derby to
>>> mysql, or you might get a 10% performance loss.  If you plan to use it
>>> commercially, use a real database because you will avoid all the issues
>>> when the database grows.  All our (non-student) databases here are
>>> 300mb-12gb. That is a very big difference to 17mb, but it depends on what
>>> data they store and how long they keep it.  17mb is just "playing".  So
>>> 10%
>>> performance difference up or down is not much fun to look at.
>>>
>>> Anyway - I don't think this is relevant to the TomEE list, and all the
>>> users/developers receiving these emails 10-20 times per day are probably
>>> not interested at all.  It's very important to keep the discussion
>>> relevant
>>> so that people don't leave the TomEE list.   The list gains more members
>>> from people seeing relevant information and staying subscribed, so we
>>> shouldn't really discuss this here as it's off-topic.
>>>
>>> You are saying your real problem is JPA, so please try on another
>>> database, and cut the problem into smaller pieces.  Then you will quickly
>>> find out if it's a Derby issue, a JPA issue, or a TomEE issue.
>>>
>>> If TomEE is performing badly compared to Tomcat or JPA on a command-line
>>> JVM, then I'm sure the TomEE devs will jump on the issue and fix it as
>>> soon
>>> as possible.  Romain is quite amazing, if he sees a problem with TomEE,
>>> he
>>> leaps on it!   So let's try to limit the number of emails to be real
>>> TomEE
>>> issues so we don't waste his time ;-)
>>>
>>> Best Regards,
>>> Neale
>>>
>>>
>>
>

Unable to configure MYSQL resource in tomee.xml

[avrono]

Hi, 

I am having a problem with configuring a database connection. I Have managed
to write to the database using   DriverManager but not with @Resource.

I have the following in my tomee.xml

 
  JdbcDriver com.mysql.jdbc.Driver 
  JdbcUrl jdbc:mysql://localhost:3306/mydb 
  UserName myuser 
  Password mypass 
  JtaManaged true 



in my ManagedBean, I have 

@Resource(name="MyDataSource", type=javax.sql.DataSource.class)
Private DataSource dataSource;


I have a @PostConstruct 

with 

try {
  connection = dataSource.getConnection();
} catch (Exception ex) {
 ex.printStackTrace();
}


The Connection does not throw an exception , however when I try write to the
connection

try {
   stmt = connection.createStatement();
   stmt.executeUpdate(insert_string)
} catch (Exception ex) {
   ex.printStackTrace()
}


I get 

Query is http://openejb.979440.n4.nabble.com/Unable-to-configure-MYSQL-resource-in-tomee-xml-tp4659538.html
Sent from the OpenEJB User mailing list archive at Nabble.com.

Re: DB access is very slow

[Neale]

Hi Howard,

Your discussions are very interesting - I haven't unsubscribed from the 
TomEE list yet even though there is such high volume.  Lately I actually 
quite enjoy following your progress.  There are a lot of emails - but just 
don't get too off-topic ;-)  Try a few things on your own, then bring your 
findings to the list.  Some questions are a bit off-topic so they're better 
being discussed on other lists.


It's really exciting seeing you using TomEE for the first time and running 
into the initial problems.  Those problems are very interesting.  When we 
get to discussing Derby vs Hyper vs MySQL however, it's better to do some 
independant research and come back to the list afterwards.  (IMHO)


Anyway - I'd love to hear more about how your project turns out, and if you 
want some free hosting on our new TomEE cluster, drop me a private email and 
I'd be happy to give you some free space.  Any experience we have with 
commerical TomEE customers is a great experience for us that we can blog 
about or share with the TomEE devs.


Best Regards,
Neale


- Original Message - 
From: "Howard W. Smith, Jr." 

To: 
Sent: Friday, December 14, 2012 5:50 AM
Subject: Re: DB access is very slow



Agreed about Romain, he is very amazing. Noted about HyperSQL, will avoid
that, and understood about 17mb = "playing". This is a new app that I've
developed and it's being used every day for 'business', so definitely not
playing, but I do want to move to prime-time and a faster database, so I
will do that, ASAP. Thanks Neale.

TomEE committers already admit that TomEE is not 'perfect'...yet, so I
would assume these discussions are welcome. Honestly, I do my best to make
sure I am on topic. I'm sure TomEE and OpenEJB is responsible for the
@Stateless EJB transaction, triggered by @Schedule, and why is TomEE
performing well with Derby when user click button, and managed beans call
@Stateless EJB (DAO) to perform database operations... but why is TomEE 
not
allowing my @Stateless EJB with @Schedule method() to perform well...with 
a

large transaction.

I have heard that geronimo has many many issues and does not have a good
name/reputation, but regardless of the negative chatter I've seen on
stackoverflow about geronimo, I still continue to use TomEE and I
communicate my issues here on the list.



On Thu, Dec 13, 2012 at 1:39 PM, Neale  wrote:


HyperSQL is another toy.

The specs below are great, Derby looks good in some cases, bad in others.
But once again this is a very small test database.

You might get 10% performance increase moving your database from derby to
mysql, or you might get a 10% performance loss.  If you plan to use it
commercially, use a real database because you will avoid all the issues
when the database grows.  All our (non-student) databases here are
300mb-12gb. That is a very big difference to 17mb, but it depends on what
data they store and how long they keep it.  17mb is just "playing".  So 
10%

performance difference up or down is not much fun to look at.

Anyway - I don't think this is relevant to the TomEE list, and all the
users/developers receiving these emails 10-20 times per day are probably
not interested at all.  It's very important to keep the discussion 
relevant

so that people don't leave the TomEE list.   The list gains more members
from people seeing relevant information and staying subscribed, so we
shouldn't really discuss this here as it's off-topic.

You are saying your real problem is JPA, so please try on another
database, and cut the problem into smaller pieces.  Then you will quickly
find out if it's a Derby issue, a JPA issue, or a TomEE issue.

If TomEE is performing badly compared to Tomcat or JPA on a command-line
JVM, then I'm sure the TomEE devs will jump on the issue and fix it as 
soon
as possible.  Romain is quite amazing, if he sees a problem with TomEE, 
he
leaps on it!   So let's try to limit the number of emails to be real 
TomEE

issues so we don't waste his time ;-)

Best Regards,
Neale

Re: DB access is very slow

[Howard W. Smith, Jr.]

Thanks Will!

On Thu, Dec 13, 2012 at 1:41 PM, Will Hoover  wrote:

> If you want speed/performance/flexibility/scalability I would recommend H2
> Database:
>
> http://www.h2database.com
>
> There's a really handy comparison matrix (Derby/HSQLDB/MySQL/PostgreSQL):
>
> http://www.h2database.com/html/features.html#comparison
>
> The nice thing about H2 Database is it can potentially simplify migration
> by
> using the available compatibility modes
> (DB2/Derby/HSQLDB/MSSQL/MySQL/Oracle/PostgreSQL):
>
> http://www.h2database.com/html/features.html#compatibility
>

Re: DB access is very slow

[Howard W. Smith, Jr.]

Smiling...forgot to mention... the database would have been much larger (if
I kept all the 'historic' / obsolete data from 1998, but decided to keep
only 3 years worth of data, and archive the rest in the old dBase IV
database files) )... the first version of my app, dBase IV app, created in
1994/1995, and recently migrated from dBAse IV to Java Server Faces web
application, and the endusers (my family) are loving the new web
application, the scalability, the accessibility, the HTML5 web application
features (can be used on mobile devices... iPad, Android, phones, tablets,
etc...) and yes, the speed too. This is the first time I actually had a
speed/performance issue, and I'm glad TomEE/openejb list is trying to help
rectify the issue.

Would I have this performance issue if I stuck it out with Glassfish? Good
question and that answer remains to be seen. I've decided to stick with
TomEE and not really use Glassfish as the 'reference implementation'. Going
forward, I'll use TomEE as the reference implementation. :)



On Thu, Dec 13, 2012 at 1:50 PM, Howard W. Smith, Jr. <
smithh032...@gmail.com> wrote:

> Agreed about Romain, he is very amazing. Noted about HyperSQL, will avoid
> that, and understood about 17mb = "playing". This is a new app that I've
> developed and it's being used every day for 'business', so definitely not
> playing, but I do want to move to prime-time and a faster database, so I
> will do that, ASAP. Thanks Neale.
>
> TomEE committers already admit that TomEE is not 'perfect'...yet, so I
> would assume these discussions are welcome. Honestly, I do my best to make
> sure I am on topic. I'm sure TomEE and OpenEJB is responsible for the
> @Stateless EJB transaction, triggered by @Schedule, and why is TomEE
> performing well with Derby when user click button, and managed beans call
> @Stateless EJB (DAO) to perform database operations... but why is TomEE not
> allowing my @Stateless EJB with @Schedule method() to perform well...with a
> large transaction.
>
> I have heard that geronimo has many many issues and does not have a good
> name/reputation, but regardless of the negative chatter I've seen on
> stackoverflow about geronimo, I still continue to use TomEE and I
> communicate my issues here on the list.
>
>
>
> On Thu, Dec 13, 2012 at 1:39 PM, Neale  wrote:
>
>> HyperSQL is another toy.
>>
>> The specs below are great, Derby looks good in some cases, bad in others.
>> But once again this is a very small test database.
>>
>> You might get 10% performance increase moving your database from derby to
>> mysql, or you might get a 10% performance loss.  If you plan to use it
>> commercially, use a real database because you will avoid all the issues
>> when the database grows.  All our (non-student) databases here are
>> 300mb-12gb. That is a very big difference to 17mb, but it depends on what
>> data they store and how long they keep it.  17mb is just "playing".  So 10%
>> performance difference up or down is not much fun to look at.
>>
>> Anyway - I don't think this is relevant to the TomEE list, and all the
>> users/developers receiving these emails 10-20 times per day are probably
>> not interested at all.  It's very important to keep the discussion relevant
>> so that people don't leave the TomEE list.   The list gains more members
>> from people seeing relevant information and staying subscribed, so we
>> shouldn't really discuss this here as it's off-topic.
>>
>> You are saying your real problem is JPA, so please try on another
>> database, and cut the problem into smaller pieces.  Then you will quickly
>> find out if it's a Derby issue, a JPA issue, or a TomEE issue.
>>
>> If TomEE is performing badly compared to Tomcat or JPA on a command-line
>> JVM, then I'm sure the TomEE devs will jump on the issue and fix it as soon
>> as possible.  Romain is quite amazing, if he sees a problem with TomEE, he
>> leaps on it!   So let's try to limit the number of emails to be real TomEE
>> issues so we don't waste his time ;-)
>>
>> Best Regards,
>> Neale
>>
>
>

Re: DB access is very slow

[Howard W. Smith, Jr.]

Agreed about Romain, he is very amazing. Noted about HyperSQL, will avoid
that, and understood about 17mb = "playing". This is a new app that I've
developed and it's being used every day for 'business', so definitely not
playing, but I do want to move to prime-time and a faster database, so I
will do that, ASAP. Thanks Neale.

TomEE committers already admit that TomEE is not 'perfect'...yet, so I
would assume these discussions are welcome. Honestly, I do my best to make
sure I am on topic. I'm sure TomEE and OpenEJB is responsible for the
@Stateless EJB transaction, triggered by @Schedule, and why is TomEE
performing well with Derby when user click button, and managed beans call
@Stateless EJB (DAO) to perform database operations... but why is TomEE not
allowing my @Stateless EJB with @Schedule method() to perform well...with a
large transaction.

I have heard that geronimo has many many issues and does not have a good
name/reputation, but regardless of the negative chatter I've seen on
stackoverflow about geronimo, I still continue to use TomEE and I
communicate my issues here on the list.



On Thu, Dec 13, 2012 at 1:39 PM, Neale  wrote:

> HyperSQL is another toy.
>
> The specs below are great, Derby looks good in some cases, bad in others.
> But once again this is a very small test database.
>
> You might get 10% performance increase moving your database from derby to
> mysql, or you might get a 10% performance loss.  If you plan to use it
> commercially, use a real database because you will avoid all the issues
> when the database grows.  All our (non-student) databases here are
> 300mb-12gb. That is a very big difference to 17mb, but it depends on what
> data they store and how long they keep it.  17mb is just "playing".  So 10%
> performance difference up or down is not much fun to look at.
>
> Anyway - I don't think this is relevant to the TomEE list, and all the
> users/developers receiving these emails 10-20 times per day are probably
> not interested at all.  It's very important to keep the discussion relevant
> so that people don't leave the TomEE list.   The list gains more members
> from people seeing relevant information and staying subscribed, so we
> shouldn't really discuss this here as it's off-topic.
>
> You are saying your real problem is JPA, so please try on another
> database, and cut the problem into smaller pieces.  Then you will quickly
> find out if it's a Derby issue, a JPA issue, or a TomEE issue.
>
> If TomEE is performing badly compared to Tomcat or JPA on a command-line
> JVM, then I'm sure the TomEE devs will jump on the issue and fix it as soon
> as possible.  Romain is quite amazing, if he sees a problem with TomEE, he
> leaps on it!   So let's try to limit the number of emails to be real TomEE
> issues so we don't waste his time ;-)
>
> Best Regards,
> Neale
>

RE: DB access is very slow

[Will Hoover]

If you want speed/performance/flexibility/scalability I would recommend H2
Database:

http://www.h2database.com

There's a really handy comparison matrix (Derby/HSQLDB/MySQL/PostgreSQL):

http://www.h2database.com/html/features.html#comparison

The nice thing about H2 Database is it can potentially simplify migration by
using the available compatibility modes
(DB2/Derby/HSQLDB/MSSQL/MySQL/Oracle/PostgreSQL):

http://www.h2database.com/html/features.html#compatibility

-Original Message-
From: Howard W. Smith, Jr. [mailto:smithh032...@gmail.com] 
Sent: Thursday, December 13, 2012 1:18 PM
To: users@openejb.apache.org
Subject: Re: DB access is very slow

Neale,

Thanks for the responses and suggestions; much appreciated.

I will definitely consider another database. I need to take some time and
dump all of the 'real' data (and the schema), and make sure the SQL and
schema will work well with a 'real' database. For the most part, it is all
SQL-92, except for Derby SQL for the identity fields for primary key columns
on 99% of the tables in the database.

Please feel free to send me a URL to a blog or two for migrating from derby
to one of the 'real' databases. Also, send me a URL to recommended 'real'
databases. MySQL and HyperSQL DB is within my radar right now.

Thanks,
Howard


On Thu, Dec 13, 2012 at 12:50 PM, Neale  wrote:

> Hi Howard,
>
> Derby is an in-memory java-based DB, so with a 100mb database it 
> performs great.
>
> Once you start putting real data into it, it fails horribly.  It's 
> designed for testing, and never for production (read the docs).
>
> Please never use it as a "production" database.  We had a customer 
> here using it, and after their database grew to 2gb in size it started 
> consuming 100% CPU on multiple CPUs and displaying huge disk I/O and 
> GC.  They converted to MySQL and their usage has dropped to less than 
> 1% of what derby was using.
>
> But it's a great DB for testing small apps, and with very small apps 
> it may even perform faster than a real DB ;-)
>
> Anyway, with your specific problem, for now I would recommend 
> separating the database and JPA so you can measure them both separately.
>
> It's always easier to solve a problem by breaking it into smaller pieces.
>
> Best Regards,
> Neale Rudd
> Metawerx Pty Ltd
> www.metawerx.net
>

Re: DB access is very slow

[Howard W. Smith, Jr.]

okay, thanks!

On Thu, Dec 13, 2012 at 1:26 PM, José Luis Cetina wrote:

> I recommend to you Mysql too.  I always used with jpa openjpa or
> eclipselink for now without problems.
>

Re: DB access is very slow

[Neale]

HyperSQL is another toy.

The specs below are great, Derby looks good in some cases, bad in others. 
But once again this is a very small test database.


You might get 10% performance increase moving your database from derby to 
mysql, or you might get a 10% performance loss.  If you plan to use it 
commercially, use a real database because you will avoid all the issues when 
the database grows.  All our (non-student) databases here are 300mb-12gb. 
That is a very big difference to 17mb, but it depends on what data they 
store and how long they keep it.  17mb is just "playing".  So 10% 
performance difference up or down is not much fun to look at.


Anyway - I don't think this is relevant to the TomEE list, and all the 
users/developers receiving these emails 10-20 times per day are probably not 
interested at all.  It's very important to keep the discussion relevant so 
that people don't leave the TomEE list.   The list gains more members from 
people seeing relevant information and staying subscribed, so we shouldn't 
really discuss this here as it's off-topic.


You are saying your real problem is JPA, so please try on another database, 
and cut the problem into smaller pieces.  Then you will quickly find out if 
it's a Derby issue, a JPA issue, or a TomEE issue.


If TomEE is performing badly compared to Tomcat or JPA on a command-line 
JVM, then I'm sure the TomEE devs will jump on the issue and fix it as soon 
as possible.  Romain is quite amazing, if he sees a problem with TomEE, he 
leaps on it!   So let's try to limit the number of emails to be real TomEE 
issues so we don't waste his time ;-)


Best Regards,
Neale

Re: DB access is very slow

[José Luis Cetina]

I recommend to you Mysql too.  I always used with jpa openjpa or
eclipselink for now without problems.
El dic 13, 2012 12:21 PM, "Romain Manni-Bucau" 
escribió:

> MySQL, don't even try hsqldb if your app has users
>
> then http://dbcopyplugin.sourceforge.net/ should help ;)
>
> Romain Manni-Bucau
> Twitter: @rmannibucau
> Blog: http://rmannibucau.wordpress.com/
> LinkedIn: http://fr.linkedin.com/in/rmannibucau
> Github: https://github.com/rmannibucau
>
>
>
> 2012/12/13 Howard W. Smith, Jr. :
> > Neale,
> >
> > Thanks for the responses and suggestions; much appreciated.
> >
> > I will definitely consider another database. I need to take some time and
> > dump all of the 'real' data (and the schema), and make sure the SQL and
> > schema will work well with a 'real' database. For the most part, it is
> all
> > SQL-92, except for Derby SQL for the identity fields for primary key
> > columns on 99% of the tables in the database.
> >
> > Please feel free to send me a URL to a blog or two for migrating from
> derby
> > to one of the 'real' databases. Also, send me a URL to recommended 'real'
> > databases. MySQL and HyperSQL DB is within my radar right now.
> >
> > Thanks,
> > Howard
> >
> >
> > On Thu, Dec 13, 2012 at 12:50 PM, Neale  wrote:
> >
> >> Hi Howard,
> >>
> >> Derby is an in-memory java-based DB, so with a 100mb database it
> performs
> >> great.
> >>
> >> Once you start putting real data into it, it fails horribly.  It's
> >> designed for testing, and never for production (read the docs).
> >>
> >> Please never use it as a "production" database.  We had a customer here
> >> using it, and after their database grew to 2gb in size it started
> consuming
> >> 100% CPU on multiple CPUs and displaying huge disk I/O and GC.  They
> >> converted to MySQL and their usage has dropped to less than 1% of what
> >> derby was using.
> >>
> >> But it's a great DB for testing small apps, and with very small apps it
> >> may even perform faster than a real DB ;-)
> >>
> >> Anyway, with your specific problem, for now I would recommend separating
> >> the database and JPA so you can measure them both separately.
> >>
> >> It's always easier to solve a problem by breaking it into smaller
> pieces.
> >>
> >> Best Regards,
> >> Neale Rudd
> >> Metawerx Pty Ltd
> >> www.metawerx.net
> >>
>

Re: DB access is very slow

[Howard W. Smith, Jr.]

Great, thanks Romain. Is MySQL still Open Source? I thought they are under
Oracle umbrella now...and I would assume there is a license or fee
involved. right?

On Thu, Dec 13, 2012 at 1:20 PM, Romain Manni-Bucau
wrote:

> MySQL, don't even try hsqldb if your app has users
>
> then http://dbcopyplugin.sourceforge.net/ should help ;)
>

Re: DB access is very slow

[Romain Manni-Bucau]

MySQL, don't even try hsqldb if your app has users

then http://dbcopyplugin.sourceforge.net/ should help ;)

Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
LinkedIn: http://fr.linkedin.com/in/rmannibucau
Github: https://github.com/rmannibucau



2012/12/13 Howard W. Smith, Jr. :
> Neale,
>
> Thanks for the responses and suggestions; much appreciated.
>
> I will definitely consider another database. I need to take some time and
> dump all of the 'real' data (and the schema), and make sure the SQL and
> schema will work well with a 'real' database. For the most part, it is all
> SQL-92, except for Derby SQL for the identity fields for primary key
> columns on 99% of the tables in the database.
>
> Please feel free to send me a URL to a blog or two for migrating from derby
> to one of the 'real' databases. Also, send me a URL to recommended 'real'
> databases. MySQL and HyperSQL DB is within my radar right now.
>
> Thanks,
> Howard
>
>
> On Thu, Dec 13, 2012 at 12:50 PM, Neale  wrote:
>
>> Hi Howard,
>>
>> Derby is an in-memory java-based DB, so with a 100mb database it performs
>> great.
>>
>> Once you start putting real data into it, it fails horribly.  It's
>> designed for testing, and never for production (read the docs).
>>
>> Please never use it as a "production" database.  We had a customer here
>> using it, and after their database grew to 2gb in size it started consuming
>> 100% CPU on multiple CPUs and displaying huge disk I/O and GC.  They
>> converted to MySQL and their usage has dropped to less than 1% of what
>> derby was using.
>>
>> But it's a great DB for testing small apps, and with very small apps it
>> may even perform faster than a real DB ;-)
>>
>> Anyway, with your specific problem, for now I would recommend separating
>> the database and JPA so you can measure them both separately.
>>
>> It's always easier to solve a problem by breaking it into smaller pieces.
>>
>> Best Regards,
>> Neale Rudd
>> Metawerx Pty Ltd
>> www.metawerx.net
>>

Re: DB access is very slow

[Howard W. Smith, Jr.]

That's the benchmark website that I've been referring to, and that is what
I've been using to justify apache derby. I don't know how reliable this
website is though. :)

On Thu, Dec 13, 2012 at 1:13 PM, Romain Manni-Bucau
wrote:

>
> yep, more or less same note can apply to windows i guess :p
>
> that's said, i'm not sure of the data but here some figures:
> http://www.jpab.org/EclipseLink/Derby/server/OpenJPA/Derby/server.html
>
> don't know why OpenJPA is so slow
>
> @Mark: any idea?
>
> FYI the same with MySQL:
> http://www.jpab.org/EclipseLink/MySQL/server/OpenJPA/MySQL/server.html

Re: DB access is very slow

[Howard W. Smith, Jr.]

Neale,

Thanks for the responses and suggestions; much appreciated.

I will definitely consider another database. I need to take some time and
dump all of the 'real' data (and the schema), and make sure the SQL and
schema will work well with a 'real' database. For the most part, it is all
SQL-92, except for Derby SQL for the identity fields for primary key
columns on 99% of the tables in the database.

Please feel free to send me a URL to a blog or two for migrating from derby
to one of the 'real' databases. Also, send me a URL to recommended 'real'
databases. MySQL and HyperSQL DB is within my radar right now.

Thanks,
Howard


On Thu, Dec 13, 2012 at 12:50 PM, Neale  wrote:

> Hi Howard,
>
> Derby is an in-memory java-based DB, so with a 100mb database it performs
> great.
>
> Once you start putting real data into it, it fails horribly.  It's
> designed for testing, and never for production (read the docs).
>
> Please never use it as a "production" database.  We had a customer here
> using it, and after their database grew to 2gb in size it started consuming
> 100% CPU on multiple CPUs and displaying huge disk I/O and GC.  They
> converted to MySQL and their usage has dropped to less than 1% of what
> derby was using.
>
> But it's a great DB for testing small apps, and with very small apps it
> may even perform faster than a real DB ;-)
>
> Anyway, with your specific problem, for now I would recommend separating
> the database and JPA so you can measure them both separately.
>
> It's always easier to solve a problem by breaking it into smaller pieces.
>
> Best Regards,
> Neale Rudd
> Metawerx Pty Ltd
> www.metawerx.net
>

Re: DB access is very slow

[Romain Manni-Bucau]

Hey,

yep, more or less same note can apply to windows i guess :p

that's said, i'm not sure of the data but here some figures:
http://www.jpab.org/EclipseLink/Derby/server/OpenJPA/Derby/server.html

don't know why OpenJPA is so slow

@Mark: any idea?

FYI the same with MySQL:
http://www.jpab.org/EclipseLink/MySQL/server/OpenJPA/MySQL/server.html

Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
LinkedIn: http://fr.linkedin.com/in/rmannibucau
Github: https://github.com/rmannibucau



2012/12/13 Neale :
> Hi Howard,
>
> Derby is an in-memory java-based DB, so with a 100mb database it performs
> great.
>
> Once you start putting real data into it, it fails horribly.  It's designed
> for testing, and never for production (read the docs).
>
> Please never use it as a "production" database.  We had a customer here
> using it, and after their database grew to 2gb in size it started consuming
> 100% CPU on multiple CPUs and displaying huge disk I/O and GC.  They
> converted to MySQL and their usage has dropped to less than 1% of what derby
> was using.
>
> But it's a great DB for testing small apps, and with very small apps it may
> even perform faster than a real DB ;-)
>
> Anyway, with your specific problem, for now I would recommend separating the
> database and JPA so you can measure them both separately.
>
> It's always easier to solve a problem by breaking it into smaller pieces.
>
> Best Regards,
> Neale Rudd
> Metawerx Pty Ltd
> www.metawerx.net
>
>
> - Original Message - From: "Howard W. Smith, Jr."
> 
> To: 
> Sent: Friday, December 14, 2012 3:48 AM
>
> Subject: Re: DB access is very slow
>
>
>> 1. In a .zip file, the Derby database is at least 17MB
>>
>> 2. yes, have indexes, i did that months ago after reviewing the apache
>> derby tuning database PDF
>>
>> 3. trust me, it is lightning fast when the 'norm' code is performing
>> database operations, concurrently; 'norm' code/approach = managed beans
>> have @EJB, @EJB = DAO
>>
>> 4.  the approach discussed in this email thread and other-related email
>> threads, I did an outside-of-the-norm approach for my app
>>
>> 5. outside-of-the-norm approach = @Stateless EJB with @Schedule method()
>> calls multiple @Stateless EJBs (DAO) to lookup as well as simple
>> insert/persist statements
>>
>> 6. lightning fast? the outside-of-the-norm approach takes 1 or 2 seconds
>> on
>> Windows Server 2008 64-bit 16GB RAM server
>>
>> 7. outside-of-the-norm appraoch takes 10 minutes on Windows Server 2003
>> 32-bit 4GB RAM server
>>
>> 8. i consider Apache Derby a real DB while others may not. I've seen
>> benchmarks, and what I saw, Derby outperforms MySQL; only other DB that I
>> would be interested in migrating to... is HSQL DB (hyper SQL DB); i think
>> that's the one shipped with our beloved 'TomEE'... Derby has
>> excellent/perfect documentation and i am very impressed with the
>> performance of Derby on the Windows Server 2003 32-bit 4GB
>>
>> 9. 'norm' concurrent operations in my app performed very well for months
>> with JSF-managed-beans on Glassfish 3.1.2.2, and the same 'norm'
>> concurrent
>> operations in my app is performing just as well now (maybe faster) on
>> TomEE
>> (CDI-managed-beans instead of JSF managed beans)
>>
>> 10. yes, i heard/know that people like to consider Apache Derby a testing
>> database, but it's definitely my production database...performing very
>> very
>> well and very reliable; honestly, i would only replace it for even better
>> performance; most of my 'norm' concurrent operations take 2 to 3 seconds;
>> user don't have to wait long at all unless i'm retrieving a bunch of rows
>> with some complicated joins involved, oh, and then the container has to
>> 'render' that data (when user selects plenty of data from database); and
>> we
>> know that rendering can hinder performance. I found that out when i
>> migrated from glassfish to tomee... had to eliminate many of the
>> rendered="..." on the popular/frequently-used xhtml pages in the app. :)
>>
>>
>> On Thu, Dec 13, 2012 at 11:27 AM, Neale  wrote:
>>
>>> How big is the DB?
>>> Do you have indexes?
>>> It should be lightning fast (1000+ requests per minute) for small DB
>>> name/address lookups.
>>> Have you tried a real DB like MariaDB/MySQL/PgSQL?  Derby is pretty
>>> terrible if the database is substantial...  good for testing small
>>> projects
>>> though.
>>>
>>
>

Re: DB access is very slow

[Howard W. Smith, Jr.]

hahaha, it is funny. :)

i will definitely consider another database, thanks.

On Thu, Dec 13, 2012 at 12:08 PM, Romain Manni-Bucau
wrote:

> funny what you call fast sounds slow for me :p
>
>
> that's said maybe try antoher database (mysql?)
>

Re: DB access is very slow

[Neale]

Hi Howard,

Derby is an in-memory java-based DB, so with a 100mb database it performs 
great.


Once you start putting real data into it, it fails horribly.  It's designed 
for testing, and never for production (read the docs).


Please never use it as a "production" database.  We had a customer here 
using it, and after their database grew to 2gb in size it started consuming 
100% CPU on multiple CPUs and displaying huge disk I/O and GC.  They 
converted to MySQL and their usage has dropped to less than 1% of what derby 
was using.


But it's a great DB for testing small apps, and with very small apps it may 
even perform faster than a real DB ;-)


Anyway, with your specific problem, for now I would recommend separating the 
database and JPA so you can measure them both separately.


It's always easier to solve a problem by breaking it into smaller pieces.

Best Regards,
Neale Rudd
Metawerx Pty Ltd
www.metawerx.net

- Original Message - 
From: "Howard W. Smith, Jr." 

To: 
Sent: Friday, December 14, 2012 3:48 AM
Subject: Re: DB access is very slow



1. In a .zip file, the Derby database is at least 17MB

2. yes, have indexes, i did that months ago after reviewing the apache
derby tuning database PDF

3. trust me, it is lightning fast when the 'norm' code is performing
database operations, concurrently; 'norm' code/approach = managed beans
have @EJB, @EJB = DAO

4.  the approach discussed in this email thread and other-related email
threads, I did an outside-of-the-norm approach for my app

5. outside-of-the-norm approach = @Stateless EJB with @Schedule method()
calls multiple @Stateless EJBs (DAO) to lookup as well as simple
insert/persist statements

6. lightning fast? the outside-of-the-norm approach takes 1 or 2 seconds 
on

Windows Server 2008 64-bit 16GB RAM server

7. outside-of-the-norm appraoch takes 10 minutes on Windows Server 2003
32-bit 4GB RAM server

8. i consider Apache Derby a real DB while others may not. I've seen
benchmarks, and what I saw, Derby outperforms MySQL; only other DB that I
would be interested in migrating to... is HSQL DB (hyper SQL DB); i think
that's the one shipped with our beloved 'TomEE'... Derby has
excellent/perfect documentation and i am very impressed with the
performance of Derby on the Windows Server 2003 32-bit 4GB

9. 'norm' concurrent operations in my app performed very well for months
with JSF-managed-beans on Glassfish 3.1.2.2, and the same 'norm' 
concurrent
operations in my app is performing just as well now (maybe faster) on 
TomEE

(CDI-managed-beans instead of JSF managed beans)

10. yes, i heard/know that people like to consider Apache Derby a testing
database, but it's definitely my production database...performing very 
very

well and very reliable; honestly, i would only replace it for even better
performance; most of my 'norm' concurrent operations take 2 to 3 seconds;
user don't have to wait long at all unless i'm retrieving a bunch of rows
with some complicated joins involved, oh, and then the container has to
'render' that data (when user selects plenty of data from database); and 
we

know that rendering can hinder performance. I found that out when i
migrated from glassfish to tomee... had to eliminate many of the
rendered="..." on the popular/frequently-used xhtml pages in the app. :)


On Thu, Dec 13, 2012 at 11:27 AM, Neale  wrote:


How big is the DB?
Do you have indexes?
It should be lightning fast (1000+ requests per minute) for small DB
name/address lookups.
Have you tried a real DB like MariaDB/MySQL/PgSQL?  Derby is pretty
terrible if the database is substantial...  good for testing small 
projects

though.

Re: DB access is very slow

[Romain Manni-Bucau]

funny what you call fast sounds slow for me :p


that's said maybe try antoher database (mysql?)

maybe the openjpa dictionnary is bad (maybe ask openjpa btw)

Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
LinkedIn: http://fr.linkedin.com/in/rmannibucau
Github: https://github.com/rmannibucau



2012/12/13 Howard W. Smith, Jr. :
> 1. In a .zip file, the Derby database is at least 17MB
>
> 2. yes, have indexes, i did that months ago after reviewing the apache
> derby tuning database PDF
>
> 3. trust me, it is lightning fast when the 'norm' code is performing
> database operations, concurrently; 'norm' code/approach = managed beans
> have @EJB, @EJB = DAO
>
> 4.  the approach discussed in this email thread and other-related email
> threads, I did an outside-of-the-norm approach for my app
>
> 5. outside-of-the-norm approach = @Stateless EJB with @Schedule method()
> calls multiple @Stateless EJBs (DAO) to lookup as well as simple
> insert/persist statements
>
> 6. lightning fast? the outside-of-the-norm approach takes 1 or 2 seconds on
> Windows Server 2008 64-bit 16GB RAM server
>
> 7. outside-of-the-norm appraoch takes 10 minutes on Windows Server 2003
> 32-bit 4GB RAM server
>
> 8. i consider Apache Derby a real DB while others may not. I've seen
> benchmarks, and what I saw, Derby outperforms MySQL; only other DB that I
> would be interested in migrating to... is HSQL DB (hyper SQL DB); i think
> that's the one shipped with our beloved 'TomEE'... Derby has
> excellent/perfect documentation and i am very impressed with the
> performance of Derby on the Windows Server 2003 32-bit 4GB
>
> 9. 'norm' concurrent operations in my app performed very well for months
> with JSF-managed-beans on Glassfish 3.1.2.2, and the same 'norm' concurrent
> operations in my app is performing just as well now (maybe faster) on TomEE
> (CDI-managed-beans instead of JSF managed beans)
>
> 10. yes, i heard/know that people like to consider Apache Derby a testing
> database, but it's definitely my production database...performing very very
> well and very reliable; honestly, i would only replace it for even better
> performance; most of my 'norm' concurrent operations take 2 to 3 seconds;
> user don't have to wait long at all unless i'm retrieving a bunch of rows
> with some complicated joins involved, oh, and then the container has to
> 'render' that data (when user selects plenty of data from database); and we
> know that rendering can hinder performance. I found that out when i
> migrated from glassfish to tomee... had to eliminate many of the
> rendered="..." on the popular/frequently-used xhtml pages in the app. :)
>
>
> On Thu, Dec 13, 2012 at 11:27 AM, Neale  wrote:
>
>> How big is the DB?
>> Do you have indexes?
>> It should be lightning fast (1000+ requests per minute) for small DB
>> name/address lookups.
>> Have you tried a real DB like MariaDB/MySQL/PgSQL?  Derby is pretty
>> terrible if the database is substantial...  good for testing small projects
>> though.
>>

Re: DB access is very slow

[Neale]

How big is the DB?
Do you have indexes?
It should be lightning fast (1000+ requests per minute) for small DB 
name/address lookups.
Have you tried a real DB like MariaDB/MySQL/PgSQL?  Derby is pretty terrible 
if the database is substantial...  good for testing small projects though.


Best Regards,
Neale



- Original Message - 
From: "Howard W. Smith, Jr." 

To: 
Sent: Friday, December 14, 2012 2:17 AM
Subject: Re: DB access is very slow


Neale,

Yes, real server that I maintain, myself, definitely 4GB RAM and Windows
Server 2003 = 32bit. :)

Howard

On Thu, Dec 13, 2012 at 10:07 AM, Neale  wrote:


Hi Howard,

Is this a real server (ie: real hardware), or a VPS that says it has "4gb
RAM, 32bit"?

Neale

- Original Message - From: "Howard W. Smith, Jr." <
smithh032...@gmail.com>
To: 
Sent: Friday, December 14, 2012 1:49 AM
Subject: Re: DB access is very slow



only queries i do is to small lookup tables... address/phone/email address
type to get the database entity. at most, those tables have 3 to 5 rows of
really really small data... Business, home, mobile (phone)...

file database? 'Apache' Derby

locks on windows... when i first developed this (few days ago), it was 
show

Apache Derby 'lock' exceptions... hahaha


On Thu, Dec 13, 2012 at 9:43 AM, Romain Manni-Bucau
wrote:

 maybe you just do too much queries and the schedul is called too

often...and you are on a file database right? so it locks on
windows...

Romain Manni-Bucau
Twitter: @rmannibucau
Blog: 
http://rmannibucau.wordpress.**com/
LinkedIn: 
http://fr.linkedin.com/in/**rmannibucau

Github: https://github.com/rmannibucau



2012/12/13 Howard W. Smith, Jr. :
> haha okay... it is  primarily a file server, also has some other >
software
> running on it, another database engine (Microsoft SQL, I think, but
that's
> not my software), that database engine is accessed by client software 
> on

> laptops connected to the LAN as well as remote connection (windows >
remote
> desktop connection)...
>
> outside of that...i really don't understand why @Stateless EJB
referencing
> other @Stateless EJB to perform database operations (insert into >
multiple
> tables...'long' transaction)...does 'not' perform well at all, >
introduces
> database locks when users are logged in the web app
>
> CDI/JSF 'managed bean' referencing @Stateless EJB to perform database
> operations has been the 'norm' in my web app, and this never introduce
> database locks, deadlock situation, or people seeing exceptions with
> eclipselink SQL in their Facesmessage after a long long wait... :)
>
> i'm going with the managed bean --> @Stateless EJB approach, just need
> to
> change around my code to do so.
>
> will keep you posted.
>
>
> On Thu, Dec 13, 2012 at 9:31 AM, Romain Manni-Bucau
> wrote:
>
>> that's not the usage of the machine :p
>>
>> Romain Manni-Bucau
>> Twitter: @rmannibucau
>> Blog: 
>> http://rmannibucau.wordpress.**com/
>> LinkedIn: 
>> http://fr.linkedin.com/in/**rmannibucau

>> Github: https://github.com/rmannibucau
>>
>>
>>
>> 2012/12/13 Howard W. Smith, Jr. :
>> > same machine
>> >
>> > On Thu, Dec 13, 2012 at 8:05 AM, Jos￯﾿ﾩ Luis Cetina <

maxtorz...@gmail.com
>> >wrote:
>> >
>> >> Where is your database, localhost?
>>

Re: EAR IN TOMEE

[José Luis Cetina]

But i have a ejb module (jar file) and a war file they are not in a ear.

Thats why Romain told that its not possible.


2012/12/13 rmpestano 

> right... IMHO it should work, producers methods were designed for that -
> initialize components with 'special' contructor -. Here we have something
> like that to inject EJBs in the same ear so the EJB is present in the
> classpath of my application(as romain  stated)  Also the scope of the
> produced EJB is important, here is what i have(similar to yours) working:
>
> @ApplicationScoped
> public class EJBProducer {
>   @Produces @RequestScoped
> public MyEJB myEJBProvider(){
> return (MyEJB ) ServiceLocator.getEJB3(MyEJB .class); //ServiceLocator do a
> jndi lookup
>  }
>
> }
>
> and i can use @Inject MyEJB  myEJB; also myEjb can participante on CDI
> events, interceptors and so on.
>
> If you use wars things are even easy you can inject the ejb directly.
>
>
>
> 2012/12/13 maxtorzito [via OpenEJB] <
> ml-node+s979440n465951...@n4.nabble.com
> >
>
> > I have @Inject. I removed by a  mistake whem i copy and paste the
> example,
> > even with that i have to do the lookup.
> >
>
>
>
> --
> Att,
>
> Rafael M. Pestano
>
> Desenvolvedor Java Cia. de Processamento de Dados do Rio Grande do Sul
> Graduando em Ciência da Computação UFRGS
> *http://conventionsframework.org*
> http://rpestano.wordpress.com/
> @realpestano
>
>
>
>
> --
> View this message in context:
> http://openejb.979440.n4.nabble.com/EAR-IN-TOMEE-tp4659241p4659519.html
> Sent from the OpenEJB User mailing list archive at Nabble.com.




-- 
---
*SCJA. José Luis Cetina*
---

Re: DB access is very slow

[Howard W. Smith, Jr.]

Neale,

Yes, real server that I maintain, myself, definitely 4GB RAM and Windows
Server 2003 = 32bit. :)

Howard

On Thu, Dec 13, 2012 at 10:07 AM, Neale  wrote:

> Hi Howard,
>
> Is this a real server (ie: real hardware), or a VPS that says it has "4gb
> RAM, 32bit"?
>
> Neale
>
> - Original Message - From: "Howard W. Smith, Jr." <
> smithh032...@gmail.com>
> To: 
> Sent: Friday, December 14, 2012 1:49 AM
> Subject: Re: DB access is very slow
>
>
>
> only queries i do is to small lookup tables... address/phone/email address
> type to get the database entity. at most, those tables have 3 to 5 rows of
> really really small data... Business, home, mobile (phone)...
>
> file database? 'Apache' Derby
>
> locks on windows... when i first developed this (few days ago), it was show
> Apache Derby 'lock' exceptions... hahaha
>
>
> On Thu, Dec 13, 2012 at 9:43 AM, Romain Manni-Bucau
> wrote:
>
>  maybe you just do too much queries and the schedul is called too
>> often...and you are on a file database right? so it locks on
>> windows...
>>
>> Romain Manni-Bucau
>> Twitter: @rmannibucau
>> Blog: http://rmannibucau.wordpress.**com/
>> LinkedIn: 
>> http://fr.linkedin.com/in/**rmannibucau
>> Github: https://github.com/rmannibucau
>>
>>
>>
>> 2012/12/13 Howard W. Smith, Jr. :
>> > haha okay... it is  primarily a file server, also has some other >
>> software
>> > running on it, another database engine (Microsoft SQL, I think, but
>> that's
>> > not my software), that database engine is accessed by client software on
>> > laptops connected to the LAN as well as remote connection (windows >
>> remote
>> > desktop connection)...
>> >
>> > outside of that...i really don't understand why @Stateless EJB
>> referencing
>> > other @Stateless EJB to perform database operations (insert into >
>> multiple
>> > tables...'long' transaction)...does 'not' perform well at all, >
>> introduces
>> > database locks when users are logged in the web app
>> >
>> > CDI/JSF 'managed bean' referencing @Stateless EJB to perform database
>> > operations has been the 'norm' in my web app, and this never introduce
>> > database locks, deadlock situation, or people seeing exceptions with
>> > eclipselink SQL in their Facesmessage after a long long wait... :)
>> >
>> > i'm going with the managed bean --> @Stateless EJB approach, just need
>> > to
>> > change around my code to do so.
>> >
>> > will keep you posted.
>> >
>> >
>> > On Thu, Dec 13, 2012 at 9:31 AM, Romain Manni-Bucau
>> > wrote:
>> >
>> >> that's not the usage of the machine :p
>> >>
>> >> Romain Manni-Bucau
>> >> Twitter: @rmannibucau
>> >> Blog: 
>> >> http://rmannibucau.wordpress.**com/
>> >> LinkedIn: 
>> >> http://fr.linkedin.com/in/**rmannibucau
>> >> Github: https://github.com/rmannibucau
>> >>
>> >>
>> >>
>> >> 2012/12/13 Howard W. Smith, Jr. :
>> >> > same machine
>> >> >
>> >> > On Thu, Dec 13, 2012 at 8:05 AM, Jos￩ Luis Cetina <
>>
>> maxtorz...@gmail.com
>> >> >wrote:
>> >> >
>> >> >> Where is your database, localhost?
>> >>
>>
>>
>

Re: DB access is very slow

[Neale]

Hi Howard,

Is this a real server (ie: real hardware), or a VPS that says it has "4gb 
RAM, 32bit"?


Neale

- Original Message - 
From: "Howard W. Smith, Jr." 

To: 
Sent: Friday, December 14, 2012 1:49 AM
Subject: Re: DB access is very slow


only queries i do is to small lookup tables... address/phone/email address
type to get the database entity. at most, those tables have 3 to 5 rows of
really really small data... Business, home, mobile (phone)...

file database? 'Apache' Derby

locks on windows... when i first developed this (few days ago), it was show
Apache Derby 'lock' exceptions... hahaha


On Thu, Dec 13, 2012 at 9:43 AM, Romain Manni-Bucau
wrote:


maybe you just do too much queries and the schedul is called too
often...and you are on a file database right? so it locks on
windows...

Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
LinkedIn: http://fr.linkedin.com/in/rmannibucau
Github: https://github.com/rmannibucau



2012/12/13 Howard W. Smith, Jr. :
> haha okay... it is  primarily a file server, also has some other 
> software

> running on it, another database engine (Microsoft SQL, I think, but
that's
> not my software), that database engine is accessed by client software on
> laptops connected to the LAN as well as remote connection (windows 
> remote

> desktop connection)...
>
> outside of that...i really don't understand why @Stateless EJB
referencing
> other @Stateless EJB to perform database operations (insert into 
> multiple
> tables...'long' transaction)...does 'not' perform well at all, 
> introduces

> database locks when users are logged in the web app
>
> CDI/JSF 'managed bean' referencing @Stateless EJB to perform database
> operations has been the 'norm' in my web app, and this never introduce
> database locks, deadlock situation, or people seeing exceptions with
> eclipselink SQL in their Facesmessage after a long long wait... :)
>
> i'm going with the managed bean --> @Stateless EJB approach, just need 
> to

> change around my code to do so.
>
> will keep you posted.
>
>
> On Thu, Dec 13, 2012 at 9:31 AM, Romain Manni-Bucau
> wrote:
>
>> that's not the usage of the machine :p
>>
>> Romain Manni-Bucau
>> Twitter: @rmannibucau
>> Blog: http://rmannibucau.wordpress.com/
>> LinkedIn: http://fr.linkedin.com/in/rmannibucau
>> Github: https://github.com/rmannibucau
>>
>>
>>
>> 2012/12/13 Howard W. Smith, Jr. :
>> > same machine
>> >
>> > On Thu, Dec 13, 2012 at 8:05 AM, Josï¿© Luis Cetina <
maxtorz...@gmail.com
>> >wrote:
>> >
>> >> Where is your database, localhost?
>>

Re: DB access is very slow

[Howard W. Smith, Jr.]

only queries i do is to small lookup tables... address/phone/email address
type to get the database entity. at most, those tables have 3 to 5 rows of
really really small data... Business, home, mobile (phone)...

file database? 'Apache' Derby

locks on windows... when i first developed this (few days ago), it was show
Apache Derby 'lock' exceptions... hahaha


On Thu, Dec 13, 2012 at 9:43 AM, Romain Manni-Bucau
wrote:

> maybe you just do too much queries and the schedul is called too
> often...and you are on a file database right? so it locks on
> windows...
>
> Romain Manni-Bucau
> Twitter: @rmannibucau
> Blog: http://rmannibucau.wordpress.com/
> LinkedIn: http://fr.linkedin.com/in/rmannibucau
> Github: https://github.com/rmannibucau
>
>
>
> 2012/12/13 Howard W. Smith, Jr. :
> > haha okay... it is  primarily a file server, also has some other software
> > running on it, another database engine (Microsoft SQL, I think, but
> that's
> > not my software), that database engine is accessed by client software on
> > laptops connected to the LAN as well as remote connection (windows remote
> > desktop connection)...
> >
> > outside of that...i really don't understand why @Stateless EJB
> referencing
> > other @Stateless EJB to perform database operations (insert into multiple
> > tables...'long' transaction)...does 'not' perform well at all, introduces
> > database locks when users are logged in the web app
> >
> > CDI/JSF 'managed bean' referencing @Stateless EJB to perform database
> > operations has been the 'norm' in my web app, and this never introduce
> > database locks, deadlock situation, or people seeing exceptions with
> > eclipselink SQL in their Facesmessage after a long long wait... :)
> >
> > i'm going with the managed bean --> @Stateless EJB approach, just need to
> > change around my code to do so.
> >
> > will keep you posted.
> >
> >
> > On Thu, Dec 13, 2012 at 9:31 AM, Romain Manni-Bucau
> > wrote:
> >
> >> that's not the usage of the machine :p
> >>
> >> Romain Manni-Bucau
> >> Twitter: @rmannibucau
> >> Blog: http://rmannibucau.wordpress.com/
> >> LinkedIn: http://fr.linkedin.com/in/rmannibucau
> >> Github: https://github.com/rmannibucau
> >>
> >>
> >>
> >> 2012/12/13 Howard W. Smith, Jr. :
> >> > same machine
> >> >
> >> > On Thu, Dec 13, 2012 at 8:05 AM, José Luis Cetina <
> maxtorz...@gmail.com
> >> >wrote:
> >> >
> >> >> Where is your database, localhost?
> >>
>

Re: DB access is very slow

[Romain Manni-Bucau]

maybe you just do too much queries and the schedul is called too
often...and you are on a file database right? so it locks on
windows...

Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
LinkedIn: http://fr.linkedin.com/in/rmannibucau
Github: https://github.com/rmannibucau



2012/12/13 Howard W. Smith, Jr. :
> haha okay... it is  primarily a file server, also has some other software
> running on it, another database engine (Microsoft SQL, I think, but that's
> not my software), that database engine is accessed by client software on
> laptops connected to the LAN as well as remote connection (windows remote
> desktop connection)...
>
> outside of that...i really don't understand why @Stateless EJB referencing
> other @Stateless EJB to perform database operations (insert into multiple
> tables...'long' transaction)...does 'not' perform well at all, introduces
> database locks when users are logged in the web app
>
> CDI/JSF 'managed bean' referencing @Stateless EJB to perform database
> operations has been the 'norm' in my web app, and this never introduce
> database locks, deadlock situation, or people seeing exceptions with
> eclipselink SQL in their Facesmessage after a long long wait... :)
>
> i'm going with the managed bean --> @Stateless EJB approach, just need to
> change around my code to do so.
>
> will keep you posted.
>
>
> On Thu, Dec 13, 2012 at 9:31 AM, Romain Manni-Bucau
> wrote:
>
>> that's not the usage of the machine :p
>>
>> Romain Manni-Bucau
>> Twitter: @rmannibucau
>> Blog: http://rmannibucau.wordpress.com/
>> LinkedIn: http://fr.linkedin.com/in/rmannibucau
>> Github: https://github.com/rmannibucau
>>
>>
>>
>> 2012/12/13 Howard W. Smith, Jr. :
>> > same machine
>> >
>> > On Thu, Dec 13, 2012 at 8:05 AM, José Luis Cetina > >wrote:
>> >
>> >> Where is your database, localhost?
>>

Re: DB access is very slow

[Howard W. Smith, Jr.]

haha okay... it is  primarily a file server, also has some other software
running on it, another database engine (Microsoft SQL, I think, but that's
not my software), that database engine is accessed by client software on
laptops connected to the LAN as well as remote connection (windows remote
desktop connection)...

outside of that...i really don't understand why @Stateless EJB referencing
other @Stateless EJB to perform database operations (insert into multiple
tables...'long' transaction)...does 'not' perform well at all, introduces
database locks when users are logged in the web app

CDI/JSF 'managed bean' referencing @Stateless EJB to perform database
operations has been the 'norm' in my web app, and this never introduce
database locks, deadlock situation, or people seeing exceptions with
eclipselink SQL in their Facesmessage after a long long wait... :)

i'm going with the managed bean --> @Stateless EJB approach, just need to
change around my code to do so.

will keep you posted.


On Thu, Dec 13, 2012 at 9:31 AM, Romain Manni-Bucau
wrote:

> that's not the usage of the machine :p
>
> Romain Manni-Bucau
> Twitter: @rmannibucau
> Blog: http://rmannibucau.wordpress.com/
> LinkedIn: http://fr.linkedin.com/in/rmannibucau
> Github: https://github.com/rmannibucau
>
>
>
> 2012/12/13 Howard W. Smith, Jr. :
> > same machine
> >
> > On Thu, Dec 13, 2012 at 8:05 AM, José Luis Cetina  >wrote:
> >
> >> Where is your database, localhost?
>

Re: DB access is very slow

[Romain Manni-Bucau]

that's not the usage of the machine :p

Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
LinkedIn: http://fr.linkedin.com/in/rmannibucau
Github: https://github.com/rmannibucau



2012/12/13 Howard W. Smith, Jr. :
> same machine
>
> On Thu, Dec 13, 2012 at 8:05 AM, José Luis Cetina wrote:
>
>> Where is your database, localhost?

Re: DB access is very slow

[Howard W. Smith, Jr.]

same machine

On Thu, Dec 13, 2012 at 8:05 AM, José Luis Cetina wrote:

> Where is your database, localhost?

Re: DB access is very slow

[Howard W. Smith, Jr.]

I had research my emails for this...

Dual Core Xeon Processor 5050 2x2MB Cache, 3.00GHz, 667MHz FSB, PE 2900
Dual Core Xeon 2nd Processor 5050, 2x2MB Cache, 3.00GHz 667MHz FSB, PE 2900
2GB 533MHz (4x512MB), Single Ranked DIMMs (replaced by 4GB RAM)
80GB, SATA, 3.5-inch 7.2K RPM Hard Drive
1TB, SATA, 3.5-inch 7.2K RPM Hard Drive (installed later; database and web
app software is here)
SAS 5/i Integrated, No RAID
Windows Server 2003 R2 Standard Edition, Includes 5 CALs
Embedded Broadcom NetXtreme II5708 GigabitEthernet NIC
PowerVault 100T, DAT72 Tape Backup, 36/72GB, w/Controller Internal for
PowerEdge 2900



On Thu, Dec 13, 2012 at 1:26 AM, Romain Manni-Bucau
wrote:

> Do you have the machine usage (cpu+mem+io)?
>
> Glassfish is not faster, eclipselink is not faster in general (depend what
> you do). Maybe you need to configure openjpa sequence to set bigger
> allocation size (openjpa.Sequence=class-tacle(Increment=1000) IIRC)
>

Re: DB access is very slow

[José Luis Cetina]

Where is your database, localhost?
El dic 13, 2012 12:27 AM, "Romain Manni-Bucau" 
escribió:

> Do you have the machine usage (cpu+mem+io)?
>
> Glassfish is not faster, eclipselink is not faster in general (depend what
> you do). Maybe you need to configure openjpa sequence to set bigger
> allocation size (openjpa.Sequence=class-tacle(Increment=1000) IIRC)
> Le 13 déc. 2012 06:18, "Howard W. Smith, Jr."  a
> écrit :
>
> > Well, my web app has performed very well with 32bit and 4GB RAM
> (Glassfish
> > and now via TomEE). I just find it strange that 'insert'
> > operations/transactions via @Stateless EJB triggered by @Schedule method
> on
> > the @Stateless EJB performs so very slow and locks the database (deadlock
> > situation) on my 32bit 4GB RAM production server, but similar
> > multiple-table update initiated by enduser performs 'very very fast' and
> > 'no' deadlock...ever!!!
> >
> > So, I'm thinking about redesigning my current implementation, the
> @Schedule
> > method on @Stateless to import some data (from customer-request emails),
> > and 'instead', present an option on the page (similar to Microsoft
> Outlook
> > and Outlook Express 'Send/Receive' option, and leave it up to the web app
> > enduser to take time out of his session to invoke the CDI @RequestScoped
> > bean to perform the multiple-table update, and then I think this way,
> there
> > will be no deadlock situation, since I never see deadlock
> > situation/exception while endusers are logged in completing all kinds of
> > database transactions 'concurrently'.
> >
> > It makes me not trust @Stateless @Schedule (background) transactions,
> since
> > it completely locks up the database, and at same time, locks up the web
> app
> > real bad!  :(
> >
> >
> > On Wed, Dec 12, 2012 at 11:27 PM, knak55 
> wrote:
> >
> > > Thank you, smithh032772,
> > >
> > > The Linux machine where I plan to deploy my application does not have
> so
> > > much memory (4GB). But the DB size is very small for the present,
> maybe a
> > > few years. So I will go with 32bit JVM at first. When the DB becomes
> > > bigger,
> > > I will move the system to 64bit environment.
> > >
> > >
> > >
> > >
> > > --
> > > View this message in context:
> > >
> >
> http://openejb.979440.n4.nabble.com/DB-access-is-very-slow-tp4659326p4659485.html
> > > Sent from the OpenEJB User mailing list archive at Nabble.com.
> > >
> >
>

Re: TomEE + maven jar hell

[Romain Manni-Bucau]

Hi,

which version?

can you share your sample?

Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
LinkedIn: http://fr.linkedin.com/in/rmannibucau
Github: https://github.com/rmannibucau



2012/12/13 robertlee :
> normally I would hate to throw undigested problem to forum users, but this
> one is getting my nerves after two days of repeated reinstallation of tomEE
> and maven repository with various dependencies combination.I am getting
> following exception... I will provide more traces at the end of this post,
> notice the class name was not able to show on the trace... can someone help?
>
>
>
> --
> View this message in context: 
> http://openejb.979440.n4.nabble.com/TomEE-maven-jar-hell-tp4659515.html
> Sent from the OpenEJB User mailing list archive at Nabble.com.

Re: TomEE EjbTimerServiceImpl ejbTimeout exception while completing container transaction

[Howard W. Smith, Jr.]

I know what I must do. Stateless ejb to stateless ejb is not how I normally
do things. I usually do updates by injecting the CDI managed beans and that
bean does update. Managed bean call other managed bean, and then that
managed bean updates database via stateless ejb.
On Dec 13, 2012 5:01 AM, "Howard W. Smith, Jr." 
wrote:

> agreed on all accounts. I may be open to increasing timeout to 30minutes.
>
> i really don't know why this takes so long... I have one page where user
> can enter a bunch of stuff, and that page saves more data then this
> operation does... and it takes 1 or 2 seconds when user click Save button
> on that ADD (data) page.
>
> gotta get to bed. :)
>
>
> On Thu, Dec 13, 2012 at 4:45 AM, Romain Manni-Bucau  > wrote:
>
>> great to hear you go further with TomEE ;) (lol)
>>
>> well think next step is to identify why you are so slow since i guess
>> you last more than 10mn
>>
>> you can configure the timeout to be 30mn but think it is a very bad idea
>> ;)
>>
>> Romain Manni-Bucau
>> Twitter: @rmannibucau
>> Blog: http://rmannibucau.wordpress.com/
>> LinkedIn: http://fr.linkedin.com/in/rmannibucau
>> Github: https://github.com/rmannibucau
>>
>>
>>
>> 2012/12/13 Howard W. Smith, Jr. :
>> > I didn't get that far with glassfish; i think i remember errors on
>> startup,
>> > trying to get the timerservice as resource. i left it alone. this is
>> first
>> > time i really used @schedule.
>> >
>> > On Thu, Dec 13, 2012 at 4:11 AM, Romain Manni-Bucau
>> > wrote:
>> >
>> >> once again the issue is probably not directly in tomee since we use it
>> >> for quite a long time
>> >>
>> >> you should just try to identify why
>> >>
>> >> a timeout is quite explicit as error, what was the one of glassfish
>> >> for transactions? think it is 10mn in tomee by default
>> >>
>> >> Romain Manni-Bucau
>> >> Twitter: @rmannibucau
>> >> Blog: http://rmannibucau.wordpress.com/
>> >> LinkedIn: http://fr.linkedin.com/in/rmannibucau
>> >> Github: https://github.com/rmannibucau
>> >>
>> >>
>> >>
>> >> 2012/12/13 Howard W. Smith, Jr. :
>> >> > Below is what I'm entering on the JIRA. very very interesting...and
>> >> > baffling! Just as I did not like the behavior of @Schedule in
>> Glassfish,
>> >> > i'm not liking the behavior of @Schedule in TomEE.  I have been
>> >> developing
>> >> > my own timers without Timer service...just use joda DateTime or
>> >> > java.util.Date. I may need to do that in this case.
>> >> >
>> >> >
>> >> > @TransactionAttribute(value = TransactionAttributeType.REQUIRES_NEW)
>> >> >
>> >> > had same test results...too.
>> >> >
>> >> > My next attempt/implementation involves the following:
>> >> >
>> >> > 1. Move all the logic of @Stateless EJB @Schedule getEmails() to
>> >> > @Asynchronous getEmails() on CDI @ApplicationScoped bean
>> >> >
>> >> > 2. Add a new method on CDI @ApplicationScoped bean called
>> >> > makeAsyncCallToGetEmails(), which will be called by @Stateless EJB
>> >> > @Schedule getEmails()
>> >> >
>> >> > 3. makeAsyncCallToGetEmails() will invoke @Asynchronous getEmails()
>> >> >
>> >> >
>> >> > So far, the test results are below. It's interesting/strange that
>> TomEE
>> >> > (the container) invokes the @Asynchronous getEmails() 'immediately'
>> after
>> >> > TomEE/container completed 'start'. See log below and look at the
>> time; I
>> >> > set the @Schedule to be 15 minutes. All the prior tests (without
>> >> > @Asynchronous), @Schedule getEmails() was invoked every 15
>> >> > minutes...working as designed. Is this a bug or feature of TomEE to
>> >> invoke
>> >> > @Asynchronous on CDI @ApplicationScoped bean immediately after
>> >> > TomEE/container starts???
>> >> >
>> >> > Well, the end result is same exception as before with a few more
>> debug
>> >> > lines. See below.
>> >> >
>> >> >
>> >> > Dec 13, 2012 3:12:07 AM org.apache.catalina.startup.Catalina start
>> >> > INFO: Server startup in 38783 ms
>> >> > Dec 13, 2012 3:16:32 AM
>> org.apache.myfaces.el.unified.ResolverBuilderBase
>> >> > sortELResolvers
>> >> > INFO: Chain of EL resolvers for Faces sorted with:
>> >> > org.apache.myfaces.el.unified.OpenWebBeansELResolverComparator@32735and
>> >> > the result order is
>> >> >
>> >>
>> [org.apache.myfaces.el.unified.resolver.implicitobject.ImplicitObjectResolver@1032447
>> >> ,
>> >> >
>> >>
>> org.apache.myfaces.el.unified.resolver.CompositeComponentELResolver@142b5f0
>> >> ,
>> >> > org.apache.myfaces.el.FlashELResolver@b6b6c6,
>> >> > org.apache.myfaces.el.unified.resolver.ManagedBeanResolver@199be0d,
>> >> > org.apache.myfaces.el.unified.resolver.ResourceResolver@8c7362,
>> >> > javax.el.ResourceBundleELResolver@eb5873,
>> >> > org.apache.myfaces.el.unified.resolver.ResourceBundleResolver@fbf8f4
>> ,
>> >> > javax.el.MapELResolver@9587c9, javax.el.ListELResolver@105ba24,
>> >> > javax.el.ArrayELResolver@ffc33f, javax.el.BeanELResolver@16b7d69,
>> >> > org.apache.webbeans.el.WebBeansELResolver@1f67d53]
>> >> > Dec 13, 2012 3:21:35 AM pf.ApplicationScopeBean log
>> >>

Re: TomEE EjbTimerServiceImpl ejbTimeout exception while completing container transaction

[Howard W. Smith, Jr.]

agreed on all accounts. I may be open to increasing timeout to 30minutes.

i really don't know why this takes so long... I have one page where user
can enter a bunch of stuff, and that page saves more data then this
operation does... and it takes 1 or 2 seconds when user click Save button
on that ADD (data) page.

gotta get to bed. :)


On Thu, Dec 13, 2012 at 4:45 AM, Romain Manni-Bucau
wrote:

> great to hear you go further with TomEE ;) (lol)
>
> well think next step is to identify why you are so slow since i guess
> you last more than 10mn
>
> you can configure the timeout to be 30mn but think it is a very bad idea ;)
>
> Romain Manni-Bucau
> Twitter: @rmannibucau
> Blog: http://rmannibucau.wordpress.com/
> LinkedIn: http://fr.linkedin.com/in/rmannibucau
> Github: https://github.com/rmannibucau
>
>
>
> 2012/12/13 Howard W. Smith, Jr. :
> > I didn't get that far with glassfish; i think i remember errors on
> startup,
> > trying to get the timerservice as resource. i left it alone. this is
> first
> > time i really used @schedule.
> >
> > On Thu, Dec 13, 2012 at 4:11 AM, Romain Manni-Bucau
> > wrote:
> >
> >> once again the issue is probably not directly in tomee since we use it
> >> for quite a long time
> >>
> >> you should just try to identify why
> >>
> >> a timeout is quite explicit as error, what was the one of glassfish
> >> for transactions? think it is 10mn in tomee by default
> >>
> >> Romain Manni-Bucau
> >> Twitter: @rmannibucau
> >> Blog: http://rmannibucau.wordpress.com/
> >> LinkedIn: http://fr.linkedin.com/in/rmannibucau
> >> Github: https://github.com/rmannibucau
> >>
> >>
> >>
> >> 2012/12/13 Howard W. Smith, Jr. :
> >> > Below is what I'm entering on the JIRA. very very interesting...and
> >> > baffling! Just as I did not like the behavior of @Schedule in
> Glassfish,
> >> > i'm not liking the behavior of @Schedule in TomEE.  I have been
> >> developing
> >> > my own timers without Timer service...just use joda DateTime or
> >> > java.util.Date. I may need to do that in this case.
> >> >
> >> >
> >> > @TransactionAttribute(value = TransactionAttributeType.REQUIRES_NEW)
> >> >
> >> > had same test results...too.
> >> >
> >> > My next attempt/implementation involves the following:
> >> >
> >> > 1. Move all the logic of @Stateless EJB @Schedule getEmails() to
> >> > @Asynchronous getEmails() on CDI @ApplicationScoped bean
> >> >
> >> > 2. Add a new method on CDI @ApplicationScoped bean called
> >> > makeAsyncCallToGetEmails(), which will be called by @Stateless EJB
> >> > @Schedule getEmails()
> >> >
> >> > 3. makeAsyncCallToGetEmails() will invoke @Asynchronous getEmails()
> >> >
> >> >
> >> > So far, the test results are below. It's interesting/strange that
> TomEE
> >> > (the container) invokes the @Asynchronous getEmails() 'immediately'
> after
> >> > TomEE/container completed 'start'. See log below and look at the
> time; I
> >> > set the @Schedule to be 15 minutes. All the prior tests (without
> >> > @Asynchronous), @Schedule getEmails() was invoked every 15
> >> > minutes...working as designed. Is this a bug or feature of TomEE to
> >> invoke
> >> > @Asynchronous on CDI @ApplicationScoped bean immediately after
> >> > TomEE/container starts???
> >> >
> >> > Well, the end result is same exception as before with a few more debug
> >> > lines. See below.
> >> >
> >> >
> >> > Dec 13, 2012 3:12:07 AM org.apache.catalina.startup.Catalina start
> >> > INFO: Server startup in 38783 ms
> >> > Dec 13, 2012 3:16:32 AM
> org.apache.myfaces.el.unified.ResolverBuilderBase
> >> > sortELResolvers
> >> > INFO: Chain of EL resolvers for Faces sorted with:
> >> > org.apache.myfaces.el.unified.OpenWebBeansELResolverComparator@32735and
> >> > the result order is
> >> >
> >>
> [org.apache.myfaces.el.unified.resolver.implicitobject.ImplicitObjectResolver@1032447
> >> ,
> >> >
> >>
> org.apache.myfaces.el.unified.resolver.CompositeComponentELResolver@142b5f0
> >> ,
> >> > org.apache.myfaces.el.FlashELResolver@b6b6c6,
> >> > org.apache.myfaces.el.unified.resolver.ManagedBeanResolver@199be0d,
> >> > org.apache.myfaces.el.unified.resolver.ResourceResolver@8c7362,
> >> > javax.el.ResourceBundleELResolver@eb5873,
> >> > org.apache.myfaces.el.unified.resolver.ResourceBundleResolver@fbf8f4,
> >> > javax.el.MapELResolver@9587c9, javax.el.ListELResolver@105ba24,
> >> > javax.el.ArrayELResolver@ffc33f, javax.el.BeanELResolver@16b7d69,
> >> > org.apache.webbeans.el.WebBeansELResolver@1f67d53]
> >> > Dec 13, 2012 3:21:35 AM pf.ApplicationScopeBean log
> >> > INFO: ApplicationScopeBean.processAirportShuttleRequest(): ADD Airport
> >> > Shuttle - Flight # 1 SUCCESSFULLY for 01/06/2013
> >> > Dec 13, 2012 3:29:10 AM pf.ApplicationScopeBean log
> >> > INFO: ApplicationScopeBean.processAirportShuttleRequest(): ADD Airport
> >> > Shuttle - Flight # 2 SUCCESSFULLY for 01/18/2012
> >> > Dec 13, 2012 3:29:11 AM pf.ApplicationScopeBean log
> >> > INFO: ApplicationScopeBean.makeAsyncCallToGetEmails(): getEmails()
> >> returned

Re: TomEE EjbTimerServiceImpl ejbTimeout exception while completing container transaction

[Romain Manni-Bucau]

great to hear you go further with TomEE ;) (lol)

well think next step is to identify why you are so slow since i guess
you last more than 10mn

you can configure the timeout to be 30mn but think it is a very bad idea ;)

Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
LinkedIn: http://fr.linkedin.com/in/rmannibucau
Github: https://github.com/rmannibucau



2012/12/13 Howard W. Smith, Jr. :
> I didn't get that far with glassfish; i think i remember errors on startup,
> trying to get the timerservice as resource. i left it alone. this is first
> time i really used @schedule.
>
> On Thu, Dec 13, 2012 at 4:11 AM, Romain Manni-Bucau
> wrote:
>
>> once again the issue is probably not directly in tomee since we use it
>> for quite a long time
>>
>> you should just try to identify why
>>
>> a timeout is quite explicit as error, what was the one of glassfish
>> for transactions? think it is 10mn in tomee by default
>>
>> Romain Manni-Bucau
>> Twitter: @rmannibucau
>> Blog: http://rmannibucau.wordpress.com/
>> LinkedIn: http://fr.linkedin.com/in/rmannibucau
>> Github: https://github.com/rmannibucau
>>
>>
>>
>> 2012/12/13 Howard W. Smith, Jr. :
>> > Below is what I'm entering on the JIRA. very very interesting...and
>> > baffling! Just as I did not like the behavior of @Schedule in Glassfish,
>> > i'm not liking the behavior of @Schedule in TomEE.  I have been
>> developing
>> > my own timers without Timer service...just use joda DateTime or
>> > java.util.Date. I may need to do that in this case.
>> >
>> >
>> > @TransactionAttribute(value = TransactionAttributeType.REQUIRES_NEW)
>> >
>> > had same test results...too.
>> >
>> > My next attempt/implementation involves the following:
>> >
>> > 1. Move all the logic of @Stateless EJB @Schedule getEmails() to
>> > @Asynchronous getEmails() on CDI @ApplicationScoped bean
>> >
>> > 2. Add a new method on CDI @ApplicationScoped bean called
>> > makeAsyncCallToGetEmails(), which will be called by @Stateless EJB
>> > @Schedule getEmails()
>> >
>> > 3. makeAsyncCallToGetEmails() will invoke @Asynchronous getEmails()
>> >
>> >
>> > So far, the test results are below. It's interesting/strange that TomEE
>> > (the container) invokes the @Asynchronous getEmails() 'immediately' after
>> > TomEE/container completed 'start'. See log below and look at the time; I
>> > set the @Schedule to be 15 minutes. All the prior tests (without
>> > @Asynchronous), @Schedule getEmails() was invoked every 15
>> > minutes...working as designed. Is this a bug or feature of TomEE to
>> invoke
>> > @Asynchronous on CDI @ApplicationScoped bean immediately after
>> > TomEE/container starts???
>> >
>> > Well, the end result is same exception as before with a few more debug
>> > lines. See below.
>> >
>> >
>> > Dec 13, 2012 3:12:07 AM org.apache.catalina.startup.Catalina start
>> > INFO: Server startup in 38783 ms
>> > Dec 13, 2012 3:16:32 AM org.apache.myfaces.el.unified.ResolverBuilderBase
>> > sortELResolvers
>> > INFO: Chain of EL resolvers for Faces sorted with:
>> > org.apache.myfaces.el.unified.OpenWebBeansELResolverComparator@32735 and
>> > the result order is
>> >
>> [org.apache.myfaces.el.unified.resolver.implicitobject.ImplicitObjectResolver@1032447
>> ,
>> >
>> org.apache.myfaces.el.unified.resolver.CompositeComponentELResolver@142b5f0
>> ,
>> > org.apache.myfaces.el.FlashELResolver@b6b6c6,
>> > org.apache.myfaces.el.unified.resolver.ManagedBeanResolver@199be0d,
>> > org.apache.myfaces.el.unified.resolver.ResourceResolver@8c7362,
>> > javax.el.ResourceBundleELResolver@eb5873,
>> > org.apache.myfaces.el.unified.resolver.ResourceBundleResolver@fbf8f4,
>> > javax.el.MapELResolver@9587c9, javax.el.ListELResolver@105ba24,
>> > javax.el.ArrayELResolver@ffc33f, javax.el.BeanELResolver@16b7d69,
>> > org.apache.webbeans.el.WebBeansELResolver@1f67d53]
>> > Dec 13, 2012 3:21:35 AM pf.ApplicationScopeBean log
>> > INFO: ApplicationScopeBean.processAirportShuttleRequest(): ADD Airport
>> > Shuttle - Flight # 1 SUCCESSFULLY for 01/06/2013
>> > Dec 13, 2012 3:29:10 AM pf.ApplicationScopeBean log
>> > INFO: ApplicationScopeBean.processAirportShuttleRequest(): ADD Airport
>> > Shuttle - Flight # 2 SUCCESSFULLY for 01/18/2012
>> > Dec 13, 2012 3:29:11 AM pf.ApplicationScopeBean log
>> > INFO: ApplicationScopeBean.makeAsyncCallToGetEmails(): getEmails()
>> returned
>> > javax.ejb.AsyncResult@1baecd3
>> > Dec 13, 2012 3:29:19 AM org.apache.openejb.core.timer.EjbTimerServiceImpl
>> > ejbTimeout
>> > WARNING: Exception occured while completing container transaction
>> > javax.transaction.RollbackException: Unable to commit: transaction marked
>> > for rollback
>> > at
>> >
>> org.apache.geronimo.transaction.manager.TransactionImpl.commit(TransactionImpl.java:272)
>> > at
>> >
>> org.apache.geronimo.transaction.manager.TransactionManagerImpl.commit(TransactionManagerImpl.java:252)
>> > at
>> >
>> org.apache.openejb.core.timer.EjbTimerServiceImpl.ejbTimeout(EjbTimerServiceImpl.java:59

Re: TomEE EjbTimerServiceImpl ejbTimeout exception while completing container transaction

[Howard W. Smith, Jr.]

I didn't get that far with glassfish; i think i remember errors on startup,
trying to get the timerservice as resource. i left it alone. this is first
time i really used @schedule.

On Thu, Dec 13, 2012 at 4:11 AM, Romain Manni-Bucau
wrote:

> once again the issue is probably not directly in tomee since we use it
> for quite a long time
>
> you should just try to identify why
>
> a timeout is quite explicit as error, what was the one of glassfish
> for transactions? think it is 10mn in tomee by default
>
> Romain Manni-Bucau
> Twitter: @rmannibucau
> Blog: http://rmannibucau.wordpress.com/
> LinkedIn: http://fr.linkedin.com/in/rmannibucau
> Github: https://github.com/rmannibucau
>
>
>
> 2012/12/13 Howard W. Smith, Jr. :
> > Below is what I'm entering on the JIRA. very very interesting...and
> > baffling! Just as I did not like the behavior of @Schedule in Glassfish,
> > i'm not liking the behavior of @Schedule in TomEE.  I have been
> developing
> > my own timers without Timer service...just use joda DateTime or
> > java.util.Date. I may need to do that in this case.
> >
> >
> > @TransactionAttribute(value = TransactionAttributeType.REQUIRES_NEW)
> >
> > had same test results...too.
> >
> > My next attempt/implementation involves the following:
> >
> > 1. Move all the logic of @Stateless EJB @Schedule getEmails() to
> > @Asynchronous getEmails() on CDI @ApplicationScoped bean
> >
> > 2. Add a new method on CDI @ApplicationScoped bean called
> > makeAsyncCallToGetEmails(), which will be called by @Stateless EJB
> > @Schedule getEmails()
> >
> > 3. makeAsyncCallToGetEmails() will invoke @Asynchronous getEmails()
> >
> >
> > So far, the test results are below. It's interesting/strange that TomEE
> > (the container) invokes the @Asynchronous getEmails() 'immediately' after
> > TomEE/container completed 'start'. See log below and look at the time; I
> > set the @Schedule to be 15 minutes. All the prior tests (without
> > @Asynchronous), @Schedule getEmails() was invoked every 15
> > minutes...working as designed. Is this a bug or feature of TomEE to
> invoke
> > @Asynchronous on CDI @ApplicationScoped bean immediately after
> > TomEE/container starts???
> >
> > Well, the end result is same exception as before with a few more debug
> > lines. See below.
> >
> >
> > Dec 13, 2012 3:12:07 AM org.apache.catalina.startup.Catalina start
> > INFO: Server startup in 38783 ms
> > Dec 13, 2012 3:16:32 AM org.apache.myfaces.el.unified.ResolverBuilderBase
> > sortELResolvers
> > INFO: Chain of EL resolvers for Faces sorted with:
> > org.apache.myfaces.el.unified.OpenWebBeansELResolverComparator@32735 and
> > the result order is
> >
> [org.apache.myfaces.el.unified.resolver.implicitobject.ImplicitObjectResolver@1032447
> ,
> >
> org.apache.myfaces.el.unified.resolver.CompositeComponentELResolver@142b5f0
> ,
> > org.apache.myfaces.el.FlashELResolver@b6b6c6,
> > org.apache.myfaces.el.unified.resolver.ManagedBeanResolver@199be0d,
> > org.apache.myfaces.el.unified.resolver.ResourceResolver@8c7362,
> > javax.el.ResourceBundleELResolver@eb5873,
> > org.apache.myfaces.el.unified.resolver.ResourceBundleResolver@fbf8f4,
> > javax.el.MapELResolver@9587c9, javax.el.ListELResolver@105ba24,
> > javax.el.ArrayELResolver@ffc33f, javax.el.BeanELResolver@16b7d69,
> > org.apache.webbeans.el.WebBeansELResolver@1f67d53]
> > Dec 13, 2012 3:21:35 AM pf.ApplicationScopeBean log
> > INFO: ApplicationScopeBean.processAirportShuttleRequest(): ADD Airport
> > Shuttle - Flight # 1 SUCCESSFULLY for 01/06/2013
> > Dec 13, 2012 3:29:10 AM pf.ApplicationScopeBean log
> > INFO: ApplicationScopeBean.processAirportShuttleRequest(): ADD Airport
> > Shuttle - Flight # 2 SUCCESSFULLY for 01/18/2012
> > Dec 13, 2012 3:29:11 AM pf.ApplicationScopeBean log
> > INFO: ApplicationScopeBean.makeAsyncCallToGetEmails(): getEmails()
> returned
> > javax.ejb.AsyncResult@1baecd3
> > Dec 13, 2012 3:29:19 AM org.apache.openejb.core.timer.EjbTimerServiceImpl
> > ejbTimeout
> > WARNING: Exception occured while completing container transaction
> > javax.transaction.RollbackException: Unable to commit: transaction marked
> > for rollback
> > at
> >
> org.apache.geronimo.transaction.manager.TransactionImpl.commit(TransactionImpl.java:272)
> > at
> >
> org.apache.geronimo.transaction.manager.TransactionManagerImpl.commit(TransactionManagerImpl.java:252)
> > at
> >
> org.apache.openejb.core.timer.EjbTimerServiceImpl.ejbTimeout(EjbTimerServiceImpl.java:598)
> > at
> >
> org.apache.openejb.core.timer.EjbTimeoutJob.execute(EjbTimeoutJob.java:39)
> > at org.quartz.core.JobRunShell.run(JobRunShell.java:213)
> > at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
> > at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
> > at java.lang.Thread.run(Unknown Source)
> > Caused by: java.lang.Exception: Transaction has timed out
> > at
> >
> org.apache.geronimo.transaction.manager.TransactionImpl.commit(TransactionImpl.java:266)
> > ... 7 more
> >
> > Dec 13, 2

Re: TomEE EjbTimerServiceImpl ejbTimeout exception while completing container transaction

[Romain Manni-Bucau]

once again the issue is probably not directly in tomee since we use it
for quite a long time

you should just try to identify why

a timeout is quite explicit as error, what was the one of glassfish
for transactions? think it is 10mn in tomee by default

Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
LinkedIn: http://fr.linkedin.com/in/rmannibucau
Github: https://github.com/rmannibucau



2012/12/13 Howard W. Smith, Jr. :
> Below is what I'm entering on the JIRA. very very interesting...and
> baffling! Just as I did not like the behavior of @Schedule in Glassfish,
> i'm not liking the behavior of @Schedule in TomEE.  I have been developing
> my own timers without Timer service...just use joda DateTime or
> java.util.Date. I may need to do that in this case.
>
>
> @TransactionAttribute(value = TransactionAttributeType.REQUIRES_NEW)
>
> had same test results...too.
>
> My next attempt/implementation involves the following:
>
> 1. Move all the logic of @Stateless EJB @Schedule getEmails() to
> @Asynchronous getEmails() on CDI @ApplicationScoped bean
>
> 2. Add a new method on CDI @ApplicationScoped bean called
> makeAsyncCallToGetEmails(), which will be called by @Stateless EJB
> @Schedule getEmails()
>
> 3. makeAsyncCallToGetEmails() will invoke @Asynchronous getEmails()
>
>
> So far, the test results are below. It's interesting/strange that TomEE
> (the container) invokes the @Asynchronous getEmails() 'immediately' after
> TomEE/container completed 'start'. See log below and look at the time; I
> set the @Schedule to be 15 minutes. All the prior tests (without
> @Asynchronous), @Schedule getEmails() was invoked every 15
> minutes...working as designed. Is this a bug or feature of TomEE to invoke
> @Asynchronous on CDI @ApplicationScoped bean immediately after
> TomEE/container starts???
>
> Well, the end result is same exception as before with a few more debug
> lines. See below.
>
>
> Dec 13, 2012 3:12:07 AM org.apache.catalina.startup.Catalina start
> INFO: Server startup in 38783 ms
> Dec 13, 2012 3:16:32 AM org.apache.myfaces.el.unified.ResolverBuilderBase
> sortELResolvers
> INFO: Chain of EL resolvers for Faces sorted with:
> org.apache.myfaces.el.unified.OpenWebBeansELResolverComparator@32735 and
> the result order is
> [org.apache.myfaces.el.unified.resolver.implicitobject.ImplicitObjectResolver@1032447,
> org.apache.myfaces.el.unified.resolver.CompositeComponentELResolver@142b5f0,
> org.apache.myfaces.el.FlashELResolver@b6b6c6,
> org.apache.myfaces.el.unified.resolver.ManagedBeanResolver@199be0d,
> org.apache.myfaces.el.unified.resolver.ResourceResolver@8c7362,
> javax.el.ResourceBundleELResolver@eb5873,
> org.apache.myfaces.el.unified.resolver.ResourceBundleResolver@fbf8f4,
> javax.el.MapELResolver@9587c9, javax.el.ListELResolver@105ba24,
> javax.el.ArrayELResolver@ffc33f, javax.el.BeanELResolver@16b7d69,
> org.apache.webbeans.el.WebBeansELResolver@1f67d53]
> Dec 13, 2012 3:21:35 AM pf.ApplicationScopeBean log
> INFO: ApplicationScopeBean.processAirportShuttleRequest(): ADD Airport
> Shuttle - Flight # 1 SUCCESSFULLY for 01/06/2013
> Dec 13, 2012 3:29:10 AM pf.ApplicationScopeBean log
> INFO: ApplicationScopeBean.processAirportShuttleRequest(): ADD Airport
> Shuttle - Flight # 2 SUCCESSFULLY for 01/18/2012
> Dec 13, 2012 3:29:11 AM pf.ApplicationScopeBean log
> INFO: ApplicationScopeBean.makeAsyncCallToGetEmails(): getEmails() returned
> javax.ejb.AsyncResult@1baecd3
> Dec 13, 2012 3:29:19 AM org.apache.openejb.core.timer.EjbTimerServiceImpl
> ejbTimeout
> WARNING: Exception occured while completing container transaction
> javax.transaction.RollbackException: Unable to commit: transaction marked
> for rollback
> at
> org.apache.geronimo.transaction.manager.TransactionImpl.commit(TransactionImpl.java:272)
> at
> org.apache.geronimo.transaction.manager.TransactionManagerImpl.commit(TransactionManagerImpl.java:252)
> at
> org.apache.openejb.core.timer.EjbTimerServiceImpl.ejbTimeout(EjbTimerServiceImpl.java:598)
> at
> org.apache.openejb.core.timer.EjbTimeoutJob.execute(EjbTimeoutJob.java:39)
> at org.quartz.core.JobRunShell.run(JobRunShell.java:213)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
> at java.lang.Thread.run(Unknown Source)
> Caused by: java.lang.Exception: Transaction has timed out
> at
> org.apache.geronimo.transaction.manager.TransactionImpl.commit(TransactionImpl.java:266)
> ... 7 more
>
> Dec 13, 2012 3:29:20 AM pf.ApplicationScopeBean log
> INFO: ApplicationScopeBean.makeAsyncCallToGetEmails(): getEmails() returned
> javax.ejb.AsyncResult@e72662
> Dec 13, 2012 3:30:01 AM pf.ApplicationScopeBean log
> INFO: ApplicationScopeBean.makeAsyncCallToGetEmails(): getEmails() returned
> javax.ejb.AsyncResult@bafb73
>
>
>
>
>
> On Thu, Dec 13, 2012 at 3:12 AM, Howard W. Smith, Jr. <
> smithh032...@gmail.com> wrote:
>
>> the following has the same test results too. 

Re: TomEE EjbTimerServiceImpl ejbTimeout exception while completing container transaction

[Howard W. Smith, Jr.]

Below is what I'm entering on the JIRA. very very interesting...and
baffling! Just as I did not like the behavior of @Schedule in Glassfish,
i'm not liking the behavior of @Schedule in TomEE.  I have been developing
my own timers without Timer service...just use joda DateTime or
java.util.Date. I may need to do that in this case.


@TransactionAttribute(value = TransactionAttributeType.REQUIRES_NEW)

had same test results...too.

My next attempt/implementation involves the following:

1. Move all the logic of @Stateless EJB @Schedule getEmails() to
@Asynchronous getEmails() on CDI @ApplicationScoped bean

2. Add a new method on CDI @ApplicationScoped bean called
makeAsyncCallToGetEmails(), which will be called by @Stateless EJB
@Schedule getEmails()

3. makeAsyncCallToGetEmails() will invoke @Asynchronous getEmails()


So far, the test results are below. It's interesting/strange that TomEE
(the container) invokes the @Asynchronous getEmails() 'immediately' after
TomEE/container completed 'start'. See log below and look at the time; I
set the @Schedule to be 15 minutes. All the prior tests (without
@Asynchronous), @Schedule getEmails() was invoked every 15
minutes...working as designed. Is this a bug or feature of TomEE to invoke
@Asynchronous on CDI @ApplicationScoped bean immediately after
TomEE/container starts???

Well, the end result is same exception as before with a few more debug
lines. See below.


Dec 13, 2012 3:12:07 AM org.apache.catalina.startup.Catalina start
INFO: Server startup in 38783 ms
Dec 13, 2012 3:16:32 AM org.apache.myfaces.el.unified.ResolverBuilderBase
sortELResolvers
INFO: Chain of EL resolvers for Faces sorted with:
org.apache.myfaces.el.unified.OpenWebBeansELResolverComparator@32735 and
the result order is
[org.apache.myfaces.el.unified.resolver.implicitobject.ImplicitObjectResolver@1032447,
org.apache.myfaces.el.unified.resolver.CompositeComponentELResolver@142b5f0,
org.apache.myfaces.el.FlashELResolver@b6b6c6,
org.apache.myfaces.el.unified.resolver.ManagedBeanResolver@199be0d,
org.apache.myfaces.el.unified.resolver.ResourceResolver@8c7362,
javax.el.ResourceBundleELResolver@eb5873,
org.apache.myfaces.el.unified.resolver.ResourceBundleResolver@fbf8f4,
javax.el.MapELResolver@9587c9, javax.el.ListELResolver@105ba24,
javax.el.ArrayELResolver@ffc33f, javax.el.BeanELResolver@16b7d69,
org.apache.webbeans.el.WebBeansELResolver@1f67d53]
Dec 13, 2012 3:21:35 AM pf.ApplicationScopeBean log
INFO: ApplicationScopeBean.processAirportShuttleRequest(): ADD Airport
Shuttle - Flight # 1 SUCCESSFULLY for 01/06/2013
Dec 13, 2012 3:29:10 AM pf.ApplicationScopeBean log
INFO: ApplicationScopeBean.processAirportShuttleRequest(): ADD Airport
Shuttle - Flight # 2 SUCCESSFULLY for 01/18/2012
Dec 13, 2012 3:29:11 AM pf.ApplicationScopeBean log
INFO: ApplicationScopeBean.makeAsyncCallToGetEmails(): getEmails() returned
javax.ejb.AsyncResult@1baecd3
Dec 13, 2012 3:29:19 AM org.apache.openejb.core.timer.EjbTimerServiceImpl
ejbTimeout
WARNING: Exception occured while completing container transaction
javax.transaction.RollbackException: Unable to commit: transaction marked
for rollback
at
org.apache.geronimo.transaction.manager.TransactionImpl.commit(TransactionImpl.java:272)
at
org.apache.geronimo.transaction.manager.TransactionManagerImpl.commit(TransactionManagerImpl.java:252)
at
org.apache.openejb.core.timer.EjbTimerServiceImpl.ejbTimeout(EjbTimerServiceImpl.java:598)
at
org.apache.openejb.core.timer.EjbTimeoutJob.execute(EjbTimeoutJob.java:39)
at org.quartz.core.JobRunShell.run(JobRunShell.java:213)
at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
Caused by: java.lang.Exception: Transaction has timed out
at
org.apache.geronimo.transaction.manager.TransactionImpl.commit(TransactionImpl.java:266)
... 7 more

Dec 13, 2012 3:29:20 AM pf.ApplicationScopeBean log
INFO: ApplicationScopeBean.makeAsyncCallToGetEmails(): getEmails() returned
javax.ejb.AsyncResult@e72662
Dec 13, 2012 3:30:01 AM pf.ApplicationScopeBean log
INFO: ApplicationScopeBean.makeAsyncCallToGetEmails(): getEmails() returned
javax.ejb.AsyncResult@bafb73





On Thu, Dec 13, 2012 at 3:12 AM, Howard W. Smith, Jr. <
smithh032...@gmail.com> wrote:

> the following has the same test results too. i'm changing my
> implementation a bit. will share more based on (or after) test results.
>
>

Re: TomEE EjbTimerServiceImpl ejbTimeout exception while completing container transaction

[Howard W. Smith, Jr.]

the following has the same test results too. i'm changing my implementation
a bit. will share more based on (or after) test results.

On Thu, Dec 13, 2012 at 2:38 AM, Howard W. Smith, Jr. <
smithh032...@gmail.com> wrote:

> Okay, I tried the following,
>
> @TransactionAttribute(value = TransactionAttributeType.REQUIRES_NEW)
>