• Post Reply Bookmark Topic Watch Topic
  • New Topic

Synchronising access to application scoped managed beans  RSS feed

 
Brendan Healey
Ranch Hand
Posts: 218
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Does anyone know if you have to use java primitives for control or whether @Lock(LockType.READ)
as used for EJB singletons would work in this context (or if there's a JSF equivalent)? I assume you
have to use primitives but wanted to make sure. I searched around and found nothing on this.

Thanks,
Brendan.
 
Tim Holloway
Bartender
Posts: 18531
61
Android Eclipse IDE Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I think you've got apples mixed in with the oranges here.

It's generally not recommended to use Domain Model objects (including EJBs) as backing beans or managed beans. If you're interested in some of the reasons, do a quick search of this forum - the issue has been discussed 2 or 3 times this year already.

In the original EJB architecture, the default behavior for methods was to serialize access. I don't think that's the case for EJB3, but I haven't checked the specs that closely, since it hasn't mattered to me lately.

A classic case that I think is like what you're asking about is where I keep a common copy of a database-backed dropdownmenu list in an application scoped bean that's read-mostly, but that I might want to allow updates without restarting the app to get the latest version of the data. For that I'm just using a POJO. By making the retrieval method either atomic or synchronized and making the updating method synchronized I can ensure application integrity. However, for that case, there's no need for annotations or framework references, since the "synchronized" feature of the core language is sufficient.
 
Brendan Healey
Ranch Hand
Posts: 218
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Tim Holloway wrote:I think you've got apples mixed in with the oranges here.


I don't think I've got anything mixed up. On the one hand, you have EJB singletons, on the other
you can also have application scoped JSF managed beans. I think there's a certain similarity
in terms of the lifetime of each. There are annotations for the EJB singleton which controls
concurrency, the default is a write lock but you can specify otherwise with the @Lock annotation.

I've got an application scoped managed bean and I had started to add @Lock(LockType.READ)
annotations to it because I've just got some static data stored, but then realised that these
are EJB annotations and not JSF. I assume that unless you specify otherwise there is no
synchronisation on a managed bean and that if you require it then you need to use JAVA
primitives, I don't think the web container does anything for you?

I wasn't very clear in my original post, I think I was at the end of a very long day, thanks
for your reply.

Regards,
Brendan.
 
Tim Holloway
Bartender
Posts: 18531
61
Android Eclipse IDE Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Actually, you're still a little fuzzy. I'm not sure if there was actually an EJB in there or not.

However, managed beans are POJOS, so there's no externally-enforced synchronization and you need the synchronization primitives if you desire it otherwise.

Actually, an application-scopy JSF backing bean is nothing but a servlet application attribute that can be constructed, initialized, and located by JSF. Other than that, it's identical to application attributes that are created and located the hard way. In fact, a servlet can't tell whether a given application scope attribute was constructed via JSF or manually.
 
Tim Holloway
Bartender
Posts: 18531
61
Android Eclipse IDE Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Actually, I just realized I'm not toally coherent myself this morning. Actually.
 
It is sorta covered in the JavaRanch Style Guide.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!