High Performance, multithreaded GORM

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

High Performance, multithreaded GORM

stanfordbangaba
Hi guys,

I love the Grails framework and have been developing applications based on it for a while.  However, I have noticed that Grails seems to have problems particularly when using GORM on high volume messaging/transaction applications.  GORM has a lot of locking and sometimes it does not even return an entity that actually exists in the database.  This might be my issue as the developer but I believe the framework is not making it any easier.  The Play Framework excels at this with the Actor Model and I would want something similar for Grails.

--
You received this message because you are subscribed to the Google Groups "Grails Dev Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/grails-dev-discuss/9dc961ab-1041-4c8b-abb5-3e7250c19ae7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: High Performance, multithreaded GORM

Jeff Scott Brown-4
On 17 Aug 2017, at 14:05, Stanford Bangaba wrote:

> Hi guys,
>
> I love the Grails framework and have been developing applications
> based on
> it for a while.  However, I have noticed that Grails seems to have
> problems
> particularly when using GORM on high volume messaging/transaction
> applications.  GORM has a lot of locking and sometimes it does not
> even
> return an entity that actually exists in the database.

Under what circumstances doe sGORM not return entities that exist in the
database?

There are times when that is the correct thing to do (depending on your
transaction isolation level, for example) but not sure if you are
describing a bug in GORM or not.

Thanks for your feedback.



JSB


--
Jeff Scott Brown
OCI Grails Practice Lead
Principal Software Engineer

Autism Strikes 1 in 166
Find The Cause ~ Find The Cure
http://www.autismspeaks.org/

--
You received this message because you are subscribed to the Google Groups "Grails Dev Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/grails-dev-discuss/B31758BF-0364-46C6-88EF-8D44726F5942%40objectcomputing.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: High Performance, multithreaded GORM

stanfordbangaba
I could be handling the transactions all wrong because there is a lot of concurrency in handling the requests and responses, I guess I need more experience in using GORM in such scenarios.  However, you might help me by suggesting how best I can implement such an application that consumes from queues and writes output to queues and also writes and updates to DB persistence where there is a lot of potential locking -- actors to the rescue?  And if so how can I use GORM in actors for example?

On Thursday, 17 August 2017 21:23:24 UTC+2, Jeff Scott Brown wrote:
On 17 Aug 2017, at 14:05, Stanford Bangaba wrote:

> Hi guys,
>
> I love the Grails framework and have been developing applications
> based on
> it for a while.  However, I have noticed that Grails seems to have
> problems
> particularly when using GORM on high volume messaging/transaction
> applications.  GORM has a lot of locking and sometimes it does not
> even
> return an entity that actually exists in the database.

Under what circumstances doe sGORM not return entities that exist in the
database?

There are times when that is the correct thing to do (depending on your
transaction isolation level, for example) but not sure if you are
describing a bug in GORM or not.

Thanks for your feedback.



JSB


--
Jeff Scott Brown
OCI Grails Practice Lead
Principal Software Engineer

Autism Strikes 1 in 166
Find The Cause ~ Find The Cure
<a href="http://www.autismspeaks.org/" target="_blank" rel="nofollow" onmousedown="this.href=&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fwww.autismspeaks.org%2F\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHLOilSQBYB1lzLN6Ms6K6DtQY5DQ&#39;;return true;" onclick="this.href=&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fwww.autismspeaks.org%2F\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHLOilSQBYB1lzLN6Ms6K6DtQY5DQ&#39;;return true;">http://www.autismspeaks.org/

--
You received this message because you are subscribed to the Google Groups "Grails Dev Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/grails-dev-discuss/7191f84c-01ab-46b7-a5c1-a991f645f259%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.